It’s more comparable to Snikket. Both Snikket and Prose use Prosody as server with their own extensions.

You could look into prose. The interface of slack/discord/mattermost, built on XMPP, with E2EE.

Bitwardens local cache does not include attachments, though. If you rely on them, you have to rely on the server being available.

So “it’s weird then”. As I said. And basically as the person I answered to said.

Yeah but why not both? Extra support shouldn’t hurt.

… each time the server restart and randomly during login.

They already accept donations as a means of continuous support. So I guess this is now just another channel for people who prefer buying a license over using github donations.

Edit: oh I just realized they stopped donations with the restructuring. Ok, that’s weird then.

Mostly a nitpick, but for that little helper I would have stuck to the stdlib and not pulled in a dependency like echo.

Otherwise: nice idea. I did something similar but since caddy runs directly on my host, I added permissions for the other services that need the cert and then pointed them directly at it.

FeedDeck

If the AppleTV allowed side loading, it would be my dream device. The UX and the speed of Apple devices are just so damn pleasing. But the artificial limits they impose on what you can run on them is damn frustrating.

SiYuan is an opensource Notion alternative. (Not a clone.)

I am surprised that no one mentioned snikket yet, which is essentially a distribution of Prosody with sane defaults and a custom client.

I meant DNS within your container network. Exposed stuff should be mapped to host ports.

The bigger issue (IMO) is, that you now have a hard requirement on the startup order of your services. If another one happens to get the IP assigned automatically befor your service starts that requests it explicitly, you now have a conflict that you manually have to resolve.

DNS is the only sane solution here.

But everyone does keep their license. A company can not really take over in the sense that you lose your old code. They can stop developing in public but keep using your code, but so can you keep using the last public version and keep developing it. Or you can take your contribution and apply it elsewhere.

Tbf, systemd also makes it relatively easy to sandbox processes. But it’s opt-in, while for containers it’s opt-out.

Props for spelling “spelling” wrong in the title .

The demo scene still exists and they still produce mind blowing stuff.

I still remember “playing” .kkrieger, a 3d shooter fitting in a fucking 64kb exe. It did use quite a bit of RAM though.

I am happy to read that there are still game devs around that give a fuck about optimizing their code. I am so sick of that whole “hardware is cheap” excuse for wasting resources.

Thinking about it… it’s probably more prevalent in game dev in general than in application software dev. But I digress.

My point however was that people who want that kind of convenience (or rather who don’t want to fiddle around manually), why would they want to run HASS in a container in the first place? Either you are tinkerer, then it doesn’t matter or you are not, in which case you probably don’t arrive at the point of running HASS on anything other than a preinstalled distro in the first place.