It's fine to as that sort of question; I wouldn't say it doesn't "belong in this community". That doesn't mean it makes sense to care about this which is what I wanted to point out.
That argument ignores that you need an account to upload pictures in most places (including here); you're already identified.
Ignoring that, while it is technically true that the Android version adds a data point and therefore identifying bits of information, you'd still be one of 105 - 106 people in the same time zone with the same device/version combo unless you're using some extremely uncommon device or are in an extremely unpopulated time zone. Compared to user agent and IP address, this is extremely little information and I'd argue quite useless without. If you need such strongly identifying data to even make any use of this, I don't think it's worth worrying about.
Besides, if you control a forum or other site that allows picture uploads and wanted to identify a user, there are so much better methods than any of this.
The software version doesn’t just say “Android 14” either. It looks very specific.
Yeah, it's likely a rather precise Android version.
So what? What does the Android version you use reveal about you? What part of your threat model does it violate?
Here, you can have the exact version of my phone: lineage_FP4-userdebug 13 TQ3A.230901.001 2023111915 test-keys. Can you identify me now?
(In my case, you theoretically actually could because my version is unique because I homebrew my Android but if you didn't know that, it'd look like any other FP4 with !lineageos@lemmy.ml on it which is why I'm not at all worried.)
No matter how you look at it, this is not an acceptable way for a device to behave, with no way to change it in settings.
Adding useful metadata that reveals no actual data about the user is a great feature and not worth adding a setting for; especially not in the UI.
I didn't know about this before but I'll look out for that whenever sends a bug report of a mobile app with screenshot as it might include the device and Android version used which is super useful info to have when troubleshooting.
You've highlighted it pretty well. But you're wrong about one thing.
Stable means the packages' interfaces remain stable. I mean that term in a very broad sense; a GUI layout would be included in my definition of an interface here.
The only feasible way of achieving that goal is to freeze the versions of the software and abstain from updating it. This creates a lot of work because newsflash: The world around you is not stable (not at all). Some parts must be updated because of changes in the world around you. The most critical here is security patches. Stable distros do backport those but usually only bother porting "important" security patches because it's so much effort.
Another aspect of this is that you usually can't introduce support for these without risking breaking older interfaces, so stable distros simply don't receive new features.
Windows 95 is one of the most stable operating systems in the world but there's a reason you're not using that (besides the security issues): At some point, you do need newer versions of interfaces to, well, interface with the world. There's newer versions of software with additional features, new communications standards and newer hardware platforms that you might want/need.
As an example: Even if you backported and patched all security issues, Firefox from 10 years ago would be quite useless today as it doesn't implement many of the standard interfaces that the modern web requires.
What you are wrong about though is that stable means no breakage or that things "run smoothly". That's not the case; stable only means that it's the same sources of breakage and same level of roughness. No new sources of breakage are introduced by the distro but the existing ones remain.
Stable distros do try and fix some bugs but what is and isn't a bug sometimes isn't easily determined as one man's bug is another man's feature. If things weren't running smoothly before, stable distros will ensure that they will run similarly roughly tomorrow but not any worse.
Well, for parts that the distro can control that is. Things outside the distro's control will inevitably break. Tools made for interfacing with 3rd party services will break when those 3rd party services inevitably change their interface; regardless of how stable the distro is (or rather precisely because of how stable the distro is).
Stable interfaces and no local regressions are what characterises stable distros. Not "no breakage", "system stability" or whatever; those qualities are independent of stable vs. fresh distros and a lot more nuanced.
Sooo Indian authorities tried to reach out to PM directly, PM didn't comply because India has no authority whatsoever over a Swiss company and PM had to ask the Swiss authorities to go tell the Indian ones to use the proper channels instead?
Yeah, Xorg (and the apps) will likely die. There is a wayland protocol in the works to be able to gracefully handle driver resets but I'm not sure on its implementation status.
amdgpu has a recovery mechanism built in that can be triggered using sudo cat /sys/kernel/debug/dri/N/amdgpu_gpu_recover where N is the number of the DRI device in question. You could bind a shortcut to doing that I presume.
I don't know shit about plural systems and have no idea about PluralKit but I can already forsee two issues that regular user accounts would have:
There may be systems who switch operators frequently; having to switch between multiple accounts could be a major hurdle for fluent conversation
Some systems may have too many operators to reasonably manage accounts for
As far as I understand it, PluralKit is more of a hack for acting as multiple pseudo-accounts with the convenience of a single (platform-) account. Given that Matrix, Element and the like are FOSS, it ought to be possible to build such a convenient single-"user" multi-account mechanisms into the clients or even protocol themselves rather than relying on hacky 3rd party add-ons.
Especially given that the user base of Matrix is far more likely to come into contact with plural systems than the general population is. (In the communities I frequent, I know of at least one and would not be surprised if there were quite a few more.)
The operating system is explicitly not virtualised with containers.
What you've described is closer to paravirtualisation where it's still a separate operating system in the guest but the hardware doesn't pretend to be physical anymore and is explicitly a software interface.
Atemu @ Atemu @lemmy.ml Posts 63Comments 1,439Joined 5 yr. ago
It's fine to as that sort of question; I wouldn't say it doesn't "belong in this community". That doesn't mean it makes sense to care about this which is what I wanted to point out.