

It depends on the phone’s brand. Samsung’s keyboard is way different from Motorola, for example. The other reasons would be the possibility of customization, and for privacy-minded people, as the keyboard is basically a very sensitive entry point


It depends on the phone’s brand. Samsung’s keyboard is way different from Motorola, for example. The other reasons would be the possibility of customization, and for privacy-minded people, as the keyboard is basically a very sensitive entry point


I believe the biggest issues of self-hosting email is the sending part, not receiving. I usually don’t have to send any emails through my aliases, I just use them so I can easily block if they start spamming, or know where a breach happened by the email, as well as to hide my main email. I know there are other use cases though, so its fair to share concerns


I’ve been working on pt-BR translations for the project, really excited about its progress and future!


Who would have thought that shoving privacy nightmare AI “tools” into the most used OS would have negative reactions huh


I highly recommend you change vendors, if possible. Not only will you not have to deal with this kind of issue anymore, you could also find vendors with dedicated support channels, status pages, and documentation detailing breaking changes (which, in an API, should only happen through versioning)


Well, it’s not easy, but I like the idea, hadn’t thought of that… I don’t really use the triggers, only when files change, so that’ll do it!


I’ve done the same. Not trusting something until it can be trusted. Unfortunately it seems there’s no easy alternative apps, so not sure how I’ll handle my usage now


I’ve been using delta for a while, alongside lazygit, and enjoying it.
I have an opinion that, as everything else in software, depends:
If there are tens of teams working on the same repo, it’s chaotic. Separating into smaller ones makes it easier to deploy, specially when there are db migrations involved.
If there are fewer teams, there’s two approaches: monolith monorepo, or monorepo with separate projects, but with single deployment pipelines. I prefer the latter, as testing changes and deployment isn’t as chaotic. I also prefer when each subproject has it’s own DB, so the migrations can be separated. There’s nothing I hate more than dealing with migration conflicts