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.
Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help,
Use -data_field first as decoder option in CLI. Default value was changed from first to auto in latest FFmpeg version. Or modify AVOption of same name in API for this decoder.
Thanks @Elon for the reply, This is the command we are currently using: ffmpeg.exe -f lavfi -i movie=flvdecoder_input223.flv[out+subcc] -y -map 0:1 ./output_p.srt
I will be looking to see any updates in the FFmpeg documentation. Can you please elaborate and provide pointers the right decoding options or the right FF command er can use. Thank you!
ffmpeg.exe -data_field first -f lavfi -i movie=flvdecoder_input223.flv[out+subcc] -y -map 0:1 ./output_p.srt
Got that’s fucking brutal. This isn’t even asking them to fix a bug, it’s just basic help-desk shit.
I’m sure Microsoft has some good devs that are a net benefit to the open source projects they use, but this is not one of them.
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.
All of this would be avoided if Debian downloaded from GitHub’s distributions of the source code, albeit unsigned.
In that case they would have just put it in the repo, and I’m not convinced anyone would have caught it. They may have obfuscated it slightly more.
It’s totally reasonable to trust a tarball signed by the maintainer, but there probably needs to be more scrutiny when a package changes hands like this one did.
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.
the wilds of Nova Scotia
Walking across the Windsor Street exchange is wild for sure.
There’s a couple of ways I could imagine debugging this.
One would be to disassemble MapEngine.MapsContainer.IsExists and see why it would throw that exception. It’s quite strange because it should act like it’s running on windows.
The other would be to enable WINEDBG stuff or possibly use strace to figure out what it did before throwing that exception.
Have you tried 32-bit wine?
This is me too, but I just switched to alacritty from urxvt (due to some new bug with control characters).
I prefer my terminal to purely show text, and I use tmux for all the fancy stuff.
Hmm, nothing there looks like an index display. My vive looks like:
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
2160x1200 89.53 +
1920x1200 89.53
1920x1080 89.53
1600x1200 89.53
1680x1050 89.53
1280x1024 89.53
1440x900 89.53
1280x800 89.53
1280x720 89.53
1024x768 89.53
800x600 89.53
720x480 60.00 59.94
640x480 60.00 59.94
Perhaps there’s a good reason for that, but this seems like a dead-end.
It should show up in the output of xrandr. At least my Vive does. Could you share that?
I believe in the past I was able to turn the display on with xrandr and extend the desktop to it. That would at least prove that the hardware works.
I feel like node’s async model makes it really easy to cause a bug like this, and really difficult to track it down.
It was left to the OS to catch the leak, because the program was written in such a way that it was able to run a gazillion of these tasks concurrently.
IMO there’s no point in optimising without being able to measure the results.
A profiler should be able to tell you how much time is spent running the code you’re attempting to optimise. It might turn out that the wine runtime code is not a significant factor in performance.
Something like this would be awesome as a core Lemmy feature IMO. It would essentially turn a post (or maybe any comment tree?) into a matrix style room. Lemmy is actually decent for long term discussion (e.g. helping someone with a problem), but not if there are more than two people involved.