I've discovered DeSEC recently too and have been positively surprised by it. I use it for DNS but they also have dyndns on a shared domain similar to DuckDNS.
Atemu
joined 4 years ago
You gave them an irrevocable license to basically use your content in any way they see fit. Them not showing posts you deleted is just them being nice, not being obligated to do so. They could simply ignore your request or restore posts later.
You should have thought about that when you gave them that license to your content.
Not really. It was publicly available information. It's, by definition, not private.
You can always use regular DNS and simply point your domain's records at hosts on your home's local network and/or the mesh VPN addresses. I do that with Tailscale.
It’s just a less expensive OEM with smaller profit margins can’t afford to do things like this
No, that's what I mean by "even if they had a typical margin". I'm saying it could be profitable despite their insane margin because you get people buying more of your products.
I wouldn't be surprised if this programme made them a rather sizeable profit even if they had a typical margin on their products.
The other replies answered your question already, but this may solve your little "problem" here: Apple offers free in-person training sessions on how to use their products. They're intended precisely for non-technical people like your mother.
So, if you don't want to be the person teaching her how to use iOS, you could look into getting her to attend these sessions instead.
You can fault Apple for many things but this offer of theirs is just great on every level IMHO.
- µG is not running as root
- It does not "already have google code in it". That's an optional, tightly scoped feature with one specific blob that is required to implement the SafetyNet feature in any implementation
- I see no reason why you couldn't run µG inside a sandbox too; the differentiating factor for security is the sandbox, not the GMS implementation. Also has nothing to do with privacy as, contrary to the original GMS, µG doesn't spy on you to begin with.
The best info you can get on "battery capacity" is what the battery controller exposes and even that's just an educated guess on its side. It's no different on macOS but at least there you have a somewhat standardised interface for this kind of information; allowing apps to access it in a generic way.
If your controller firmware doesn't expose the info to the kernel, you won't be getting it, sorry.
I doubt this is a hardware issue though. Even a battery at 80% capacity won't lose it all overnight when the device is actually in deep sleep.
With this many services each doing their own power management, I would not be surprised if it never got there. Do a bug report and analyse it using battery historian to get an idea of where the power draw comes from.
An easier test would be to simply shut all of those services down for a given time frame, measure power draw (%/h) and compare to when all of them are running. Safe mode might come in handy here as you can be sure there's no user app running in that state. If it's many % per hour in that state, there's either an issue with the OS or indeed the HW.
Why go through all of that complexity when you could just sudo apt install docker?
That mitigates a rather minimal leak while ignoring the gaping black data hole.
I'll let you in on a little secret: Fstab gets converted to mount units anyways.