It’s more comparable to Snikket. Both Snikket and Prose use Prosody as server with their own extensions.
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.
What’s wrong with that? Do you expect their backend to run off a single server with a little PHP script? The components seem pretty reasonable (with the actual business logic being just a small part).
Bitwardens local cache does not include attachments, though. If you rely on them, you have to rely on the server being available.
So they have two airflows? Then I assume in contrast to the ones with just one exhaust they need two fans? One for circulating (and cooling) the air from the room and one to circulate the air from (and to) the outside?
Then I assume that would make them even noisier then the single exhaust ones, right? (More moving parts.)
Two tubes still means it pulls in hot air from the outside that it then needs to cool down first. The split ACs are basically the only sane ones (but expensive).
That invitation confused me hard. With the picture of a city I expected to find a location somewhere. But then it was a relatively subtle word “online” on a link deeper down that finally gave away that it’s an online meetup.
Yeah but why not both? Extra support shouldn’t hurt.
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.
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.
Lookup if the device is supported by LocalTuya though.
I made the mistake thinking that LocalTuya somehow acts like a proxy for a generic protocol, but it actually needs to understand the devices. Now I have a doorbell I can’t use with it.
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.
The problem is, that it doesn’t even have to be “evil”. Most people make assumptions. If you notice or suspect a question carrying an assumption, I think it’s the right thing to clear things up. A yes or no is simply not enough if the whole premise of the question might be flawed.
That always makes me angry in court scenes in TV, although there it’s likely intentional and therefore your mentioned “evil question”. I hope that shit doesn’t fly in real courtrooms.
Not just scrollbars. Buttons, input fields, etc.
Dammit I sometimes have to search for elements I can interact with. Back in the day it was self explaining.
But that’s the neat thing: the system is well structured into different layers and subcomponents. They are not all involved to control lightbulbs; that’s mostly your local hue bridge. One component will make sure, Alexa can control your bulbs (if you want that). If that component fails, only Alexa stops working. Another component handles push notifications to your mobile devices. If that fails, the rest is unimpacted. And so on.
That was, for a long time, the main reason I heavily recommended Hue: the bridge can be used completely offline and still offered a good local API and pairing system. Unfortunately last year that made online accounts a requirement. I assume besides the App you can still use many things even if your network connection is broken, though.