orange @ orange @communick.news

Posts

0

Comments

9

Joined

1 yr. ago

Since Mint is based on a stable distro, it'll be running older software that won't support your newer hardware well, and you're experiencing that firsthand.

Try Fedora, Bazzite, OpenSUSE Tumbleweed, or anything else that's more bleeding edge – they're still very usable and reliable, it's just that stable distros like Mint and Debian are "stable and reliable" overkill.

Edit: and if you're wondering why this wasn't mentioned to you from the start, the answer is likely that these distros tend to be:

1. Less popular and get fewer mentions and votes, and
2. Are considered riskier in an enterprise context, so stable distros are deemed a safe recommendation since the odds of things going wrong on supported hardware is extremely low.

Overlap with desktop Linux means support for that is support for these mobile Linux distros, and desktop Linux gets support from a range of people and companies, not just Google.

That's becoming less true. The cost of inference has been rising with bigger models, and even more so with "reasoning models".

Regardless, at the scale of 100M users, big one-off costs start looking small.

Because the Linux Foundation says so. I would guess it's because most of the relevant tech started as cloud products or services and got generalised, such as Kubernetes (the big one in CNCF).

The naming wasn't up to Bazzite or uBlue to decide, that's for sure, and the term "cloud native" has won the mindshare of developers.

The irony hits hard when you're logging into an on-prem Kubernetes cluster in your company's wholly owned data centre. At that point, "cloud" isn't even someone else's computer (as the FSF would say).

From what I've heard at work and from others, MS uses version queries to stall tickets because they constantly release updates that they can point to and say "you need to update before we can help".

No, Play Integrity intentionally checks if it's a Google-approved key. Android itself has an API to check verified boot and gives info on the signing key - most devs just want to know verified boot is working.

I feel Play Integrity has a short life ahead of if competition authorities realise how exactly it works. "Anti-competitive" is the first thing policy-minded folks think when I explain the API to them.

For GrapheneOS, it's primarily that it's re-lockable. That's why other unlockable phones aren't supported.

The GrapheneOS install process sets new OS signing keys so you can lock the phone again and get full verified boot. However, most manufacturers haven't implemented this feature.

I think it might be confusion between inspecting plaintext metadata like SNI vs actually inspecting encrypted contents (e.g. HTTPS content, headers, etc.).

Ublue also has Asus-specific variants which I assume probably has some compatibility fixes added in that would have to be installed manually in most other distros.

Since you use VS Code I'd strongly recommend the developer variants of ublue, which are only available for Aurora and Bluefin, as it gives you a preinstalled VS Code which will be a better experience than trying to install it after the fact. (if you go to the download page for them, answer "yes" to "are you a developer?")

For minimum learning curve, use Aurora over Bluefin as the UI is more familiar. Also, make sure you pick the Nvidia option for the GPU question.