Maybe this explains why my webcam indicator is on when no applications are using it. It's been confusing me for a while now. I've double checked anything that I expect to access it is not, and it doesn't seem to be locked because opening it works, but it sometimes boots up woth the light on. I am using Arch with pipewire so I'll check and see if this is what's going on.
Mastodon added text search a while ago.
I'm not sure about FF specifically, but 99% of the time you're connecting a microcontroller to a PC you're doing so over a serial port (UART) of some sort. It may be a physical COM port or it may be a USB to serial adapter or even a purely virtual serial port over a USB connection, but the methodology is all the same. Unless you are running a serial terminal on that port (as in, a commandline on your PC served on the given /dev/ttyX interface, not a terminal emulator letting you read/write from the port), the microcontroller can't just run scripts on the PC. Instead, you will want to write a script/program that opens the port and waits for a command to be sent from the microcontroller, then that listener script can execute whatever functionality you require. Note that only one application can have the port active at a time, so if your listener is a separate program from your event handler, you will have to close the port on the listener before running the handler, then reopen the port on the listener once the handler is done so it can start listening for the next event. Better to just make it all one program that is always running on the PC and does both listening for events and handling them so there's only one program that needs access to the serial port.
It would be nice to see Linux benchmarks for new hardware too. Love GN's content but I basically ignore his benchmarks as they're done on Windows. It shows the relative strengths of the hardware but not real world Linux performance.
While I'm not a fan of advertising or marketing in general, brands having a presence on the Fediverse would be great for Fediverse adoption, and sometimes complaining about a brand on social media is needed to get proper customer service in this world of AI and bot controlled customer service channels. I can see this being a good thing, and there are some brands/companies I would likely follow. I already do follow a few who are on Mastodon, such as Framework, Pine64, and Raspberry Pi.
Interesting, though I question why a battery backed RTC is seen as so critically important. Of all the features I can think of wanting in a router, a battery backed RTC doesn't even begin to make the cut. A device that is powered up 24/7 and connected to the Internet can just get NTP time whenever it boots up and keep time using the OS. What is so necessary about an RTC here? I get that time is used for certificate verification and other security stuff, but again NTP and always powered. Are they concerned that NTP could be an attack vector?
I'm interested in a new OpenWRT router as my WRT1900ACS is getting older and the WiFi driver on it never had amazing support. Right now the Banana Pi R4 looks promising as a WiFi 7 OpenWRT supported router as it looks like most off the shelf WiFi 7 routers do not have OpenWRT support.
Where did it say 90Hz? That sounds like a HUGE upgrade. The OLED image quality will be nice but higher refresh rate is something I've really wanted, though unfortunately I haven't seen anything regarding VRR.
I would pay for Amazon Prime if they offered purely a free 2-day shipping only version, but I refuse to pay for Prime if it supports the media companies, so I don't pay for Prime. I have zero interest in DRM-filled "you will own nothing and be happy" streaming bullshit, and I have negative interest in the same thing with ads. Enshittification at its finest.
I had to RMA mine at the beginning of the year for pretty much the same issue. It would throttle the CPU to like 400MHz in any sort of gaming workload no matter how light. I reinstalled the OS, reset the BIOS, battery storage mode, even unplugged the battery and plugged it back in but nothing fixed it. Valve sent me a brand new unit in its place. Valve's RMA is top notch. Mine was only around 6 months old at the time so 1.5 years is awesome that they're still doing it.
At least we know all the returns aren't just being scrapped now that they're selling official refurbished units. That's where all of the RMA units are going I suppose.
They started out doing well but they're getting worse IMO. They nerfed the CI availability into the ground for open source project use to the point it's basically unusable. You eat up your pathetic 400 minutes a month in no time. Basically, if you want CI you have to provide your own runners now. They have definitely been following the enshittification trends of late. They grew to prominence as an open source GitHub alternative and now they barely support open source on the platform. Definitely hoping a third alternative becomes viable with CI that is actually usable for open source projects.
This is why I trust GPL licenses over things like MIT. Fully permissive licenses are ripe for developers to sell out. GPL licenses ensure the code remains open and limits even what the original developer can do (so long as they merge a sufficient number of third party changes to make relicensing impossible). Permissive licenses allow developers to close off future updates should they desire. I haven't looked at the license of Mastodon's code to be fair, I'm just speaking in general.
The kernel driver is a rather small piece of the overall puzzle though, itps just the pipe that GPU commands are passed through. The bulk of the GPU driver code (and the majority of its impact on performance) is in the userspace components like the shader compiler and the OpenGL/Vulkan libraries. These are closed source.
The exception to this rule is that the kernel driver is responsible for power management and controls the GPU clocks, but as part of opening up the kernel driver NVIDIA made reclocking available for the fully open driver (nouveau/nvk) to use as well which means the performance differences between the two driver stacks are now down to optimizations.