No, it absolutely uses a Linux kernel.
mr47
Your screenshot does not really show anything other than the fact that Ally attempts a connection to Facebook (it's not even clear how it was blocked). You can see the amount of people telling you to unblock NTP, which you stated isn't blocked - that's a clear sign that you haven't presented you data in an easy to review format.
Why not show what exactly is blocked by the firewall, how the rules are configured, and disabling which rule exactly gets the app to work? E.g., if you block Facebook by redirecting to your own HTTP server that responds, the app may decide to bork because of a failed certificate validation - resolve the Facebook domain as NXDOMAIN in your DNS, and see if that helps.
The fact that they use Facebook APIs is infuriating, regardless.
https://github.com/technicalpickles/homesick
It's a bit old (hasn't been updated in 4 years), but works great.
Exactly. The issue is with the source of electricity, not with the AC itself. Not to mention that leading by example is nice, but it's not always the best course of action. An individual avoiding AC is a drop in the water, and not going to save the planet, while suffering immensely. Hell, even if every single individual stopped using AC at home (which isn't even close to reality), that wouldn't have a significant effect, compared to what corporations, factories, etc. are doing.
Not necessarily demanding, but Uncharted is a very pretty game, and fun, too.
Yep - and in that case, what you interact is, is your instance. You have no direct interaction with the Threads server, whatsoever. Your instance pulls that content (which is publicly available!), and shows it to you. If you comment on it, you do so on your instance, and it federates that comment back to the Threads instance (where the data federated is publicly available - it's the content of your comment, and your handle). There's nothing malicious going on here.
That's not to say that something bad can't happen in the long run. E.g., if people get used to content from Threads, and then Threads suddenly stops supporting ActivityPub (or forks it with negative changes), many people might be lured to start using Threads in order to keep accessing its content. That's definitely a potential issue. But the technical side of federating with Threads is absolutely benign.
No, you couldn't. Why are you spreading misinformation? You are posting to your instance, and that's federated to Threads. Threads isn't getting any information about you that isn't publicly available.
Hear me out. Why don't we create a paywalled API for 3rd party apps (like Threads), that will end up costing, say, $20 million annually to use at Meta's rate... And then use the proceeds to keep all the instances running, and for other shenanigan.
That's a really nice setup! I run most of my things on a docker swarm (the docker hosts are VMs running on Proxmox hosts), though that was an overkill in retrospect, and causes more problems with no practical advantages.
The range of services I run is similar to yours, but I also have a bunch of services for personal finance (beancont/fava, as well as automatic importers and such), a more extensive media setup (with qBitTorrent and *arr apps), a gitea server, and a vaultwarden instance.
That awesomebudget looks nice! I'm more of a beancont/fava guy, and too invested in my setup to try something vastly different - but it sure looks like a cool option for people starting out.
What about kbin?
A custom made Google Sheet to track everything - maintenance, repairs, insurance, and fuel ups. I'd like to move to an app that supports all of the above, but getting everything into an importable format was messy (tried it with Fuelio), and I gave up after a while. The fact that I'm also writing down parts purchased prior to installation does not make this easier.
My plan is to try and convert it all into plaintext accounting format (probably Beancont with a tailor-made plugin), but so far I've been mostly kicking that ball down the street.