nitrolife

If you are using only Docker, you don’t need a Linux distribution at all. Just install alpine slim, busybox, or any Kubernetes worker node build.

Flatpak, much like snap, appimage, and other programs trying to shove old, hole-ridden libraries down my throat under the pretext that “the build is too complex,” is not the kind of software I would welcome on my PC. I’d rather build the application by hand.

Not only with intervals but also with quite old software. Sometimes software versions are so old that they are no longer compatible with the upstream version. Although, to be honest, I haven’t used Debian for so long that I can’t even name the applications that lagged behind like that.

In general, Debian is indeed incredibly stable, but if you need to install it on the latest laptop (for example, Intel Core Ultra X9), it will be a real hell.

UPD: except perhaps for using sid. But then you lose the only advantage - stability.

Just recently, someone wrote about https://github.com/stalwartlabs/stalwart here. It is literally an all-in-one server, so it’s quite hard to mess up.

Email itself is an unreliable delivery method, so usually, if a server cannot send an email to the recipient’s server, it puts it in a queue and tries again after some time. Therefore, a few hours of downtime won’t affect you much. Especially if you don’t need an archive of your correspondence.

So I still recommend trying to run your own full server with stalwart. At most, a couple of days of problems, and then it will work for years.

Yes, possibly. In general, I was wrong.

P.S. very cool server, but it’s a pity there is no analog of dovecot dsync in it. I had already prepared the deployment when I realized that I wouldn’t be able to run 2 isolated servers with synchronization.

Unfortunately, I lost the section. But I’ve already been told that everything works correctly according to the tests, so I was just mistaken.

Thank you. Apparently, I misunderstood the documentation. I will try to deploy it anyway.

In principle, it’s a pretty good “all-in-one” server, and I even wanted to switch to them until I checked the documentation and saw that the Community version doesn’t filter From with valid authentication. This means that anyone who is properly authorized can send an email from any address on the server out of the box. In short, if I understood the documentation correctly, it’s a decent option for hosting your own mailbox, but for even small-scale mass use, postfix + dovecot still wins.

Just like before, I update frequently. Although now I’ve switched to updating once a month instead of once a week. And I maintain an enforced SELinux configuration and some other tools. That’s all. I host quite a lot of services on the internet.

front: open-webui skill servers: dockling - docs parsing for llm, searxng - searchengine for llm, open-terminal - linux terminal for llm (inside container) base: llama-swap Inside llama swap: qwen3-14b-q5, translator-nemo-12b, tower-plus-9b, translator-gemma4-26b, qwen3.6-35b-a3b llama stack: ROCm

Hardware: RX9070XT for llama-swap .

UPD: if you want easy way and run all in oneshot use https://github.com/Niko1221/Strata

If I just drop a link into IRC, Jabber, Matrix, and possibly Discord, every client will go to the server and request a preview. The only difference is how many clients are online. On sufficiently large servers, this can also cause a DDoS. The problem lies in server-side caching, not in the architecture of all messengers.

UPD: of course, this can be solved on the Lemmy side, but what will you do when the network grows even larger? A million servers will cause a DDoS even with random requests. You could of course send the preview with the post, but it seems that would permanently and strictly limit the type of preview, and it’s unclear how to handle custom servers.

SSO doesn’t work like that. Conventionally, there is an sso ml provider, an sso world provider, and anyone else from the fediverse. Any server, for example lemmy, looks at the login domain during authorization and sends a request to the server along the lines of “someone is trying to log in, send the cookies and a redirect link”; someone is redirected to the SSO server, authenticates there, and then returns back to the original lemmy node. The registration endpoint can be determined by the domain.

Like, for example, lemmy.world login 1234@lemmy.ml -> redirect to lemmy.ml for password -> redirect to lemmy.world back. Or any another instance in fediverse.

Accordingly, this is literally no different from what exists now except for one nuance — I won’t need to go to my instance anymore, find a post mirrored from world, and write a comment there. I will simply be able to log in directly on world and write whatever I want.

And passwords are in the hands of the node admins anyway. This will literally differ from the current scheme in nothing except that potentially the owner of your lemmy account could hijack your mastodon. But those who actually think about this will just make 2 SSO accounts. But how easy that will be. No 20 accounts in 20 instances… And no one will have to explain why they need 20 accounts at all. And I’ll finally be able to watch pirtube, read lemmy, and comment on mastodon from the same username. =)

UPD: Especially tough guys will just be able to host their SSO node and not bother with password hijack.

Passport verification is a terrible idea. Instead of passport verification, the fediverse really lacks separating auth servers into a separate SSO component. So that you could log in to every fedi instance with the same account. It would be super convenient, and those who like to keep everything close together could just run two components side by side.

Yes, I installed an LLM at home. I use it for many useful things:

1. reading novels by translating them from English to my language on the fly via machine
2. for communicating on lemmy by translating posts and comments
3. For HomeAssistant
4. And very rarely for development and searching the internet

I have a RX9070XT and llama-swap to switch models on the fly. I’m thinking about installing a second RX9070XT so that I don’t take away the translation capability from my lemmy instance while I stress the other neural network with other tasks.

Install a clean Arch, then install Podman and run the wolf container. You will have everything needed in the containers. If you wish to play directly in your browser, run the moonlight-web container next to the wolf.

SNAP in the recommended packages of the ubuntu-server metapackage. Ubuntu installs all recommended packages by default. So SNAP is in the server installation, moreover, it can’t even be simply removed without completely blocking in apt policy.

SNAP also doesn’t work well with old hardware because of compression. It’s ironic to recommend system riddled with incompatible compression to someone who explicitly wrote in a post that they would be using outdated hardware.

If you’re planning to use old hardware for hosting, don’t use Ubuntu. SNAP will kill performance.

So your choice is Debian.

P.S. VPS is already a Virtual Private Server and you can’t install ProxMox or any virtualization on it. If you want experiments, look into containers.

In any program, you still have to execute a challenge somewhere. No program will issue certificates without that. In the case of certbot, you can simply write a small post hook that will transfer the certificates to cloudflare.

Just don’t expose SSH to internet. It’s a complex protocol with many CVEs. And you realyy don’t need access to SSH from anywhere. Replace access from ineternet to a WireGuard tunnel that has almost zero attack surface area and properly configured iptables rules. And that’s it.

I think the problem has been slightly exaggerated. If you’re not hosting several dozen services, you can reduce your attack surface down to one Nginx server. For an even stricter setup, just enable mTLS.