- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
There is this bug in TIC-80.
When running the wasm version on firefox it has very bad framerate.
So as many before me I pulled my sleeved and opened the firefox profiler to see what’s going on. Well the framerate has never been better. As soon as you turn of the profiler the framerate drops.
I thought I was going insane, until I saw that other people luckily found the same behavior. For now the unofficial fix is opening the firefox profiler when playing on firefox.
There’s a weird obscure bug in M$ Remote Desktop in Windows 11 Pro I spent entirely too much time trying to track down, as a user. (Yes, the first mistake was ever getting near Windows, but anyway.)
It looks like there is some kind of counter that now exists in number of logged in sessions, and each RDP session counts as a one-time-use session. The local user does too.
- If you log in locally on first boot, there’s a 25% chance you’ll be able to log in remotely from one machine once or twice.
- If you log in as a remote user from boot, you’re more free to log in remotely, possibly from two different machines about 75% of the time, but if you just use one other machine, pretty much forever.
- Rebooting always solves the login issues, so much so that a terrible terrible workaround was employed. Enable OpenSSH server (now included in Windows) on Windows, to SSH into the box (which, reliably works every time no matter what) and reboot it.
- So many Internets on the topics, including using their old RDP driver, that the new driver may be cranky, that the host graphics drivers may have an impact, that the BIOS OOB management may have an effect. Nothing ever fixed it consistently.
Thankfully, my life means too much to me to go further down the rabbit hole and I don’t have to use Windows as much anymore, and hopefully soon never, but…its like they took a whole team of engineers to break something that has worked amazing since the early aughts and just firehosed pigeon turds all over it.
They obviously care enough to keep it working as they renamed the RDP app to “Windows App” in the last year, but don’t care enough to make it work correctly?
Hm sounds like the bug is in the code that handles the “one session only” rule
Per Microshits T&Cs you can only have 1 session of any kind at a time unless you get the super special business multi seat RDP license (because ofc)
I actually have a Powershell script I found awhile back that patches the RDP DLL so it stops caring about multiple sessions
I spent entirely too much time trying to track down
Been there, if you have the audacity to force your way into the WindowsApps folder you’ll bork the permissions systems so bad that every single post about how to fix it ends in “just reinstall” me being me that was an unacceptable answer.
Took me a week to fix it so the MS store would launch again. On the flip side, I have a whole new understanding of the permissions system on windows. Heh
Trying to reproduce a bug that consistently only shows up the first time we boot up our machines that day. Currently testing to see how long the machine needs to be off in order for the bug to show up again. I’m at an hour now.
Could the time delay in being able to reproduce relate to some piece of code that has a timeout (thinking login timeout, cookie expiration, auth timeout, that sort of thing.) Or likewise, if the computer in question has multiple shutdown phases, like how many computers today “sleep” to RAM, and then an hour later sleep to disk in a more hibernatey fashion and fully power off? (Or some weirdness like how Windows shutdown now is ostensibly a hibernate, but a reboot is actually a full “power down power up” without shutting off power.)
I like @[email protected] 's take on being wall-clock-based. I once had a bug with some software that would just go belly-up on certain days for no reason whatsoever in a datacenter 2000 miles away. After having worked on some bare metal servers in the past and learned all about thermal issues firsthand, I checked the weather in that region. It only seemed to happen on extremely hot summer days, at the day’s temperature peak. Turns out the datacenter vendor had a cooling problem in that section of the DC and they were unaware of it…
Crazy sometimes how bugs manifest.
Another angle to try is to set the date one day ahead and see if the bug shows up then. Might need to disconnect from network and set it in the BIOS for the test to work properly.
I could be wrong, but I figure after being off for an hour, all capacitors should have discharged by then, so it’s probably not based on how long the hardware has been unpowered.
Though one other angle I just thought of, if you have something that runs periodically, maybe the bug is related to that period being missed once or n times. Or it could be related to something that is meant to wake the computer to run some job and then go back to sleep but instead just sets it in a bad state.
The date/time aspect is an interesting thought. For a bit more context, this machine is a Raspberry Pi connected to several other devices, some via USB and some via a CAN network. The system gets powered on manually, the user performs a task, then shuts it down until they need it again. We only use the date/time for logging. The system is connected to our wifi at our facility but after we ship it then it’s likely it will never be connected to the internet except maybe when we’re servicing it and updating code. I don’t think the Pi has a RTC. I don’t really see how the date/time could be causing the issue I’m seeing (seems to be lag in communication with the devices on the CAN network) but I guess stranger things have happened.
Oh, apologies for my suggestion before seeing this comment hahaha!
CAN devices I have limited experience with, but I know at least in the automotive industry, vehicles often have various CAN devices that have various sleep states. Like, shut car off, it holds brake system for a few minutes and then unlocks the brakes and that ECU shuts down. Later on, an emissions ECU may run a self-diagnostic. After a few days being powered off, the security ECU goes into low power and turns off wireless doorlocks. After the voltage drops too low, the ECU in the head unit ostensibly shuts down, and the next time the car is started, the head unit has to do a cold-reboot and takes a fortnight.
Could be one of those CAN devices takes some time to get into the “off-adjacent” state to manifest the bug?
Ah that’s interesting. If you can swap the devices from one pi to another, try powering it all up on machine A, then swap the devices to machine B and power that on. Might tell you if the issue is with on the pi side or with the devices.
Is latency higher on the first boot than on subsequent ones? I’d be looking into race conditions if you’re seeing a bit of lag cascade out into bigger problems. Race conditions are the worst, especially when the race most often goes the right way and just occasionally goes the wrong way. Though you can force the wrong way by adding delays in your code, if you have an idea of where the race is happening.
Then you find out that the bug only works when it’s a Tuesday on a leap year and only if you have Albanian input method enabled.
Or, after weeks of debugging an issue the user has logs proving they are having weird performance issues despite having a strong GPU, it turns out their parents wouldn’t let them take that GPU out of the family PC so they rigged up a PCIe to USB to wireless transmitter that hooks up to a wireless to USB to serial port that exploits a signal leaking from serial port to PCIe bus bug on the family PC motherboard to act as if the GPU is on their own machine, which both impresses and horrifies you.
And when you try to get approval to drop the issue as unsupported, your manager gives you shit and it takes another week to convince him that it isn’t a use case that you should support. And they only agreed in the end because a more senior technical person happened to overhear you pleading with your manager one day and only had to say, “that’s crazy!” for your manager to 180 immediately on the issue. But it’s still cited as a negative on your next performance review (“you spent weeks working on something we don’t even support!”).
…this hurts my brain. That being said, I’d probably also try it for the lulz, but I’d never bother support about it, because I knew what I was doing was insane.
Wow there bud, oddly specific
Just made that one up but it was based on another Frankenstein-like setup another user in a beta testing group was using that I don’t remember the specifics of. His issues started getting mostly ignored until he upgraded his system to something more normal lol.
Haha gotcha. I’ll be honest that’d be a brilliant hack if someone managed to make it work.
Impressive engineering, but it comes with a curse.
Where it gets messy is you’d need to supply power on the PCIe rail as well as any extra plugs the GPU needs without powering on the system itself. And then even messier if someone powers on that system. Mad scientist shit.
thought this was about arthropods
Damn this meme image is crisp as fuck.
It’s rare to see a newborn meme. Soon it will be pixelified to all the doom.
Did the episode even originally air in standard definition?
Is it really a meme without a certain amount of jpeg?
Also applies to spiders