Have you checked these all on winehq? It would be nice for them to be reported with logs if they haven’t already.
Garmin Express for example is on there with some discussion here: https://appdb.winehq.org/objectManager.php?sClass=version&iId=40213
It might not help in the short term, but even just having logs for more broken programs could be useful for the wine project.
I love that you have a very specific and arguably moral crime in mind, and it inspired this post.
Did you grep that log file for ‘amdgpu’?
I wonder if the error is related to this: https://github.com/NixOS/nixpkgs/issues/229108
I’m still using x11 on my system. Maybe try that and see if it works?
No, I haven’t seen anything like that. That’s odd.
I’ve had those errors on my system for years. I never thought that they were NixOS specific. I just assumed something to do with a buggy firmware:
Enabled 4 GPEs in block 00 to 1F
ACPI Error: Aborting method \_SB.PCI0.GPP2.PTXH.RHUB.POT3._PLD due to previous error (AE_AML_UNINITIALIZED_ELEMENT) (20240322/psparse-529)
[x~20]
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
I don’t notice any ill-effects from them, so it may be a red herring. I have a:
$ < /sys/devices/virtual/dmi/id/board_name
ROG STRIX B450-F GAMING
with a 5900X.
I don’t usually see as many prints as you have there, but it’s quite a few, and the number seems to vary (grow?) over time. I keep meaning to investigate it, but haven’t got around to it.
I think you should keep looking in your logs for other problems. If you can share the full log I’d be happy to take a look.
The original error actually makes it sound like there’s a partition on hda that’s bigger than hda itself.
It probably becomes CPU limited with those other compression algorithms.
You could use something like atop to find the bottleneck.
Sounds like it’s not really a downgrade, but just an unreleased beta or test build? That seems a little less sketchy, and maybe it’ll be generally released at some point.
I’d probably:
systemctl suspendWhen the screen fails to wake, are you able to get it back by powering it off, or by unplugging it? Is it X or wayland?
Of course not, but you have to either trust your users to some extent or give them a system that’s locked down to the point of hindering them.
What is ‘unallowed software’? A shell script the user wrote? Something they downloaded and compiled?
Limiting that seems fundamentally at odds with FOSS.
If you stop shipping autotools generated artefacts in your tarballs, things will be a lot simpler.
Weirdly enough the malicious code does look eerily similar to the benign code, because both are unnecessarily obfuscated.
This is not a human written or readable file you’re talking about. It’s a generated script.
As the other user suggested, you probably just need to mount the root subvolume somewhere and run it on that.
Try using btdu. I’m not sure how it works with compression, but it at least understands snapshots, as long as they are named in a sane way.
Yeah, that’s fair. If you want to test that you can still decompress something compressed with some random old version, you either need to keep the old algorithm around, or the data.
Many of the files have been created by hand with a hex editor, thus there is no better “source code” than the files themselves.
I don’t buy that. There would have been some rationale behind the contents that could be automated, like “compressed file with bytes 3-7 in the header zeroed”.
You also probably don’t need these test files to be available in the environment where the library itself is built. There are various ways you could avoid that.
I do agree about the autotools stuff though.
Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer’s computer.
This seems avoidable. We shouldn’t be copying code around like that.
They are actually not that much bigger or different from mobile or game console GPUs, they just have a lot of cooling bolted to them. The cooling allows them to sacrifice efficiency, to be more power hungry and more powerful.
I wonder if anyone is doing large scale searches for source releases that differ in meaningful ways from their corresponding public repos.
It’s probably tough due to autotools and that sort of thing.
it had a way to know it was being emissions tested and so it adapted to that.
Not sure why you got downvoted. This is a good analogy. It does a lot of checks to try to disable itself in testing environments. For example, setting TERM will turn it off.
I’d just count calories and reduce the amount per day until you’re losing weight.
The time of day you eat things shouldn’t really matter. This will also teach you really quickly how to feel full on minimal calories. For me I just try to eat something like raw carrots when I want a snack.