

Cuute
Eskating cyclist, gamer and enjoyer of anime. Probably an artist. Also I code sometimes, pretty much just to mod titanfall 2 tho.
Introverted, yet I enjoy discussion to a fault.


Cuute
TL;DR
Install an archival version of Bazzite or whatever else that corresponds to a date when you know it worked correctly.
Bazzite in particular makes this fairly easy. They have straight forward instructions on how to roll back to a given version.
If that fixes it, just use that version and don’t update.
If you want to stick with Cachy, you can use the Arch Archive to downgrade your entire system to an earlier date, or just Gamescope.
AND I AM TELLING YOU TO DOWNGRADE THEM SO YOU CAN SEE IF AN EARLIER VERSION WORKS CORRECTLY, INSTEAD OF SWAPPING OUT THE ENTIRE DISTRO
ONLY TO TRY THE EXACT SAME COMPOSITOR AS IF THAT WOULD FIX IT
So instead of that, try earlier versions! Different distros from the same date are obviously likely to be running similar versions of Gamescope or whatever else might be the cause.
No.
We use the word distro because they’re not really a fully separate OS. Just a different preset with either a lot or almost nothing swapped out as compared to the next.
You are so hung up being correct here you’re missing what I’m actually trying to teach you.
You need to be comparing different versions, not distros. Because the same version of the same software is going to have the same problem, no matter what distro you use.
You don’t even know how to access system logs, and you expect to understand enough about this stuff to successfully correct me on why trying a different distro isn’t that helpful for troubleshooting?
Software packages that are different.
No? The same software is the same software, regardless what distro you install it on.
Gamescope running on top of KDE/Plasma in one distro will not be different from Gamescope running on top of KDE/Plasma in another distro.
Distros are just presets. The vast majority have far more similarities than differences.
What makes one distro different from another, is that it might come with gnome instead of KDE, pacman instead of apt, initd instead of systemd, systemd-boot instead of grub.
Or any other litany of alternative packages that do the same things.
But if you use the same software, then there is little difference between one distro and the next. The main difference is going to be that you installed the same code from a different distributor.
That’s literally where the name “distro” comes from.
Yes.
A distro or distribution is just a collection of software packages, and usually a package manager.
The actual software itself is the same. The list can be different, but where the items overlap, they are the same. How up to date they are can vary, but Plasma 6 on Bazzite is the exact same as Plasma 6 on Cachy.
Systemd is the same systemd across arch, ubuntu, mint, endeavour, fedora, and any others that use it.
Is this not obvius?
Changing the distro does not tell you much. Especially as you’re running the exact same program in the exact same DE, you should absolutely expect the same result.
I don’t have the slightest clue how to do anything with snapshots and it’s been months since it began anyway so I wouldn’t even know where to start
Well, if you didn’t create any, you can’t go back to them.
My suggestion is to find the archival ISOs of older versions and try them WITHOUT updating after installing them offline.
Though, if you end up having to install gamescope from the internet, then you’re likely getting the exact same latest version no matter what distro you use.
Hence, maybe just easier to learn how to install older versions of packages on cachy. The Arch archive repo makes that quite doable.
And even if I did know which version caused the problem, I wouldn’t know where to go from there.
You pin the package/system and prevent it from updating so it keeps working for you. And report the bug so it can be fixed.
All of this stuff is a community effort. You can wait for someone else to figure out the problem of course, but the fastest solution is usually to volunteer yourself.
A different distro is not different software. Distros are really just different ways to install the same exact software.
Gamescope on Bazzite is the same as Gamescope on Cachy. Same for Plasma/KDE.
Why would they be different?
Learn.
Start with googling how to use journalctl, filter it based on time, errors, or specific processes.
Gamescope is an extra tool.
By going back in time to a version that you know worked.
If that doesn’t fix it, then you can be sure the problem is hardware related, because it still happens on the exact same software that used to work.
And if it does work on older software, then you can go forward one update/snapshot at a time, until you find the change that causes the problem.
What you need to do is compare different points in TIME (older versions), not the same software just installed differently.
Step one for me whenever I run into an issue, is to load up an earlier system snapshot and see if that fixes it.
If it does, it was an update that changed something. If it doesn’t, it’s likely a hardware issue.


Huh.
I never thought of using that feature of btrfs that way. Brilliant.
Which this looks like it can be.
If you don’t provide consent for the app stats, and don’t create an account (which you don’t actually have to) they don’t have a basis to track anything.
Basically, what you want to look for in GDPR compliant privacy policies, is “we don’t keep/use the data”.
That’s because of how GDPR defines “legitimate interest”.
If you have a website, or handle ANY traffic, at all, under GDPR you actually cannot legally claim something like “we don’t collect your IP address”. Unless the user is behind a VPN, your server does at least for the duration of a users interaction, technically, know their IP. Which means you have to state you collect IPs as defined by “legitimate interest”.
You can only then add that you don’t do anything with that data. Which this privacy policy does do.
Basically, everything under “legitmate interest” is just “this is how the internet works” or otherwise self evident stuff, like if you write your email in a contact form, you’re providing your email for the purpose of being contacted.
Everything that does not fall under “legitimate interest” under GDPR requires “explicit consent” meaning no such piece of data can be gathered without giving the user an explicit readable prompt, that either explains what is happening or links to the privacy policy.
“Legitimate interests” is the legal term used in GDPR to refer to things you can’t avoid collecting. Like someone’s email address when they create an account on your platform.
You will find a mention in literally every single legally compliant privacy policy.
This privacy policy is pretty much the bare minimum you have to have to be legally compliant in the EU, even if you literally never save anything or do anything with the data. Because just by having people visiting your website you technically “know” their IPs even if you don’t save them.
If someone sends you an email, then you technically “collect” their name and address. If you sell something, then you technically “collect” customer transaction data.
Literally every privacy policy that wants to be GDPR compliant has to mention “legitimate interest” and it literally just means “when you tell us stuff, that means we then know that stuff about you”.
This privacy policy is pretty explicit about NOT doing anything beyond the bare minimum.
It does allow them to collect their own statistics, but there is no clause allowing stats or other data to be personally identifiable (except for authentication), and more notably, that would allow data to be re-sold or shared.
We do not collect usage data about other apps on your device or websites that are not our own.
Smart Launcher’s app sorting feature is entirely optional. If you choose to enable it, we may collect information about the apps installed on your device, but only after obtaining your explicit consent. If you do not grant permission, no data will be collected. When collected, this data remains anonymous, as it is transmitted separately from any personally identifiable information. We use it solely to enhance your experience, and it is never shared with third parties.
We only use technical cookies to ensure the proper functioning of our website and apps. These cookies do not track your activity for advertising purposes.
If you log in to our services using third-party authentication providers (e.g., Google Login), we may collect personal information such as your email address and other information shared by the third-party provider based on your consent. This information is used solely for authentication purposes.
Some features, like searching contacts, require access to your Address Book. We do not collect or share this data. This permission is optional and can be enabled or disabled at any time.
The app may require access to your location, for example, to display the weather forecast. In such cases, we share your approximate location (city level) with the weather forecast provider to enable the service. This permission is optional and can be granted or revoked at any time.
Access to Storage: The app may need access to your storage, for instance, to allow you to search for a specific picture or file, or to access the wallpaper in use. We do not collect or share this data. This permission is optional and can be granted or revoked at any time.
Additionally, a GDPR compliant privacy policy must be exhaustive. Even with the device identifier, if the data-point isn’t in the list, they can’t legally collect it.
That means the optional list of the apps you have installed that they use to develop their auto-categorization of apps, is about as bad as it gets. This isn’t covered by GDPRs definition of legitimate interest, which is why it requires explicit consent.
(Smart launchers titular feature is that it will automatically let you navigate your apps by categories like games, financial, social, tools, etc.)
I mean… I kinda did?
https://www.smartlauncher.net/privacy
Seems reasonable.
Bare minimum, clearly discloses what they may have access to based on how you use the software, and that they do not forward it to any third parties.
I’ve been meaning to watch Sisu.


I mean, presumably this is all device-side on the stick.
It mounts the two partitions separately, and presents them separately. It doesn’t need to pass through the actual SD card to the host system at all.
If you dd the decoy partition you only ever see the decoy partition. Because the decoy partition is presented as a complete device, not just a partition, to the host system.
Why would this be incompatible with linux? If this is done the way it seems it is done, it’s not a filesystem trick.
It’s two partitions on one SD card being presented as two separate devices by the microcontroller that has actual direct access.
The real vulnerability would be that you could just crack it open to find the SD card.
I would add that a slightly better way would be to do it in raid1 mode instead of single mode.
That way you can move the data over by running a balance, instead of by removing the old volume, which would survive the process being interrupted by a reboot or whatever else.
Then after the balance you can remove the old volume and turn the new one back into a single mode volume.