BobVonBob

Ironically, entering a given BIOS screen becomes more difficult the more you know about them. As far as I can recall I've seen BIOS keys on F1, F2, F9, F10, F11, F12, and Delete. Worse still manufacturers will switch the key between models, or even generations of the same model. And just to twist the knife a little more many have secondary functions like one-time boot menus and diagnostics on the other keys, so mashing them all at once just sends you somewhere random. And the cherry on top, the internet is dead and searching for the answer will just lead you to page after page of SEO-optimized drivel from an LLM with 50/50 odds on hallucinating the wrong key.

A GPU is not just a bunch of small CPUs. It's optimized for SIMD workloads, single instruction multiple data. In order to effectively leverage that for compilation it would need to be doing the same thing at the same time across many files. There is actually one use case where GPU compilation is relatively common, and that's shader pre-compilation. Shaders are often many tiny bits of code, and they're usually similar and simple enough that they don't need much effort to optimize during compile time. That combination of small size and simple compilation (i.e. low memory requirements, because GPUs do not have much memory if you split it across many tasks) makes them perfect to compile on a GPU, but most standard compilation tasks are not like that. With regards to LLVM, I think you've misunderstood it. LLVM can compile code which runs on GPUs, but it does not compile code on a GPU. LLVM is a toolchain to create compilers, and it's often used when making a compiler for new languages. You make a program to turn your language into LLVM's intermediate representation and LLVM handles optimizing that and turning it into machine code.

It turns out a hardware accelerator for compiling would look almost exactly like a CPU. It would need to perform large, varied, sequential tasks as fast as possible, and that happens to be what CPUs are already good at. The way we write programs makes them unfriendly to parallelism. Consider the following: int a = 5; int b = a + 2; int c = a + b; Each line changes the state of the program, and the following lines depend on that change, so how would you break this up to compile in parallel? GPUs are great at performing tons of small, highly repetitive, independent computations, and it turns out a lot of what we do on computers can be split up into small, highly repetitive, independent computations, but compiling is not one of those things.

There's two types of EDID support, EDID passthrough and EDID emulation, and to my knowledge the two are incompatible. Passthrough is just forwarding the EDID information straight through to the video source, while EDID emulation fakes the EDID information. Passthrough works basically like the display is directly connected, things like HDCP and variable refresh rate will work as expected, but the source will know when it's been disconnected from the display. Emulation breaks things like HDCP and VRR, but it can make the source believe a display is connected when it isn't, or believe that it's a different display entirely, which could be preferred in some scenarios. Support for neither just combines all of the downsides of both with none of the upsides.

Annoyingly L1T doesn't have the right photo angles to determine if the holes for the rack mount brackets are there, but luckily their OEM Rextron does. Yes, the HDMI 2.1 version supports the rack mount kit. The primary difference is that the HDMI version has hardware to deal with HDMI embedded audio, either feeding audio into it or extracting audio from it. Your other concerns then are just what ports most of your hardware uses (swapping with converters is possible, but with a KVM in the mix it's usually a good idea to keep the rest of the signal path as simple as possible) and the HDMI 2.1 KVM currently being out of stock.

On the contrary, unless you have plans to add a phantom power microphone, an instrument, or a MIDI device in the near future I would suggest the setup just use a DAC or DAC/amp (i.e. any amplifier with digital inputs, and thus a built-in DAC) instead of an interface like that. You'll avoid paying for hardware you aren't going to use and you can spend that on features that might actually be useful in your situation like a remote.

Those are system files, not remnants from the old drive. Every partition you currently have should stay exactly as it is, you just need to remove the drive letters from the E and F drives. You should be able to do that with diskpart. Launch an admin terminal (either cmd or powershell, admin powershell can be accessed in the menu opened by the shortcut Win + X). Type in diskpart and press enter, then enter remove letter=E and remove letter=F. They should have their letters removed and be gone from explorer.

This is a classic case of not my job. Let IT deal with the IT, and the consequences if the new password manager is a flop. Unless you're making the decisions there's not much you can do about bad ones except keep your CV up to date.

To get HDMI 2.1 at that length you need a fiber optic cable, every copper cable that long claiming HDMI 2.1 is a scam. I know Club3D and Cable Matters make 10m cables that will do 2.1 speeds. There are other brands out there with fiber optic cables half their price, but I can't vouch for them.

That's just the thing, if you're using rechargeable batteries not a single battery gets used up in the entire lifetime of the controller. I've been using the same pack of rechargeable AA batteries since the late Xbox 360 era and they're still going strong enough for my tastes, not to mention I'd already have them anyway because of all the other stuff in my house that needs AA/AAA batteries. Granted I'm not a heavy controller user, but they've seen enough use and time to have killed at least one and possibly two lithium ion batteries. Everything being land waste straight out of the factory nowadays is a separate issue, but I'd argue removable standardized batteries are also a boon there because at least you aren't throwing out a working battery too. However, while the best case battery waste scenario is better than built-in batteries, you do have a point that using the AA battery form factor at all means people that still haven't caught on have the option to use and waste disposable batteries, which is an issue. (Seriously people they're like twice the price of disposable batteries now. IKEA sells fantastic rechargeable batteries almost everywhere in the world get with the program.)

Agreed for disposable batteries, awful wasteful things that should have been phased out a decade ago. But I absolutely disagree for rechargeables. The lifetimes of products and their built in batteries, especially for relatively low cost devices like controllers, are often tied to each other. Sure it's possible to replace built-in batteries, have a repair shop replace them, or remove and reuse/recycle them if the product they're in breaks, but that never happens. On a macro scale essentially nobody is bothering to do that, they just throw the whole thing away and get a new one. Rechargeable standard sized batteries sidestep this issue by decoupling the batteries and the product they're in. And if the time to replace batteries is your biggest gripe, there are countless rechargeable battery packs (an additional cost, the downside of this) for Xbox controllers that not only make recharging the same as a controller with built-in batteries, but also allow the batteries and controller to be independently replaced easily enough that an average person might be expected to do so.

I don't think a 256GB SSD is enough for three operating systems, but if you want to try I think 128 GB for Windows and 64 GB each for Arch and Nobara would be your best bet. If you really want to expand the Arch space at all costs perhaps 96 GB for Windows, 128 for Arch, and 32 for Nobara? I absolutely would not try to shrink the Windows partition any more than that, and even 96 will probably be a tight squeeze.

Core Utility and Total CPU Utility include turbo/PBO speeds. It's normal (and expected) for them to read more than 100%.

I doubt the exact price will be leaked before launch day, but I'd expect them to be pretty expensive like their other original products.

Not sure what it was, but taking a stab in the dark I suspect it was an issue with bidirectional bluetooth. Bluetooth massively reduces audio quality when using a device as both an audio input and output. Games are pretty likely to automatically pick up microphones, while most other applications won't. To fix it, just disable the associated input device in your audio devices and use a different microphone.

Most string to numeric converting functions have bounds checking, and the ones that don't shouldn't be used on values that could be outside of the acceptable range. In the case of C with an unsigned integer you would generally use strtoul(), which sets errno if the value is out of bounds. You can check that as follows: #include <errno.h> #include <stdlib.h> int main(void) { const char *strNum = "-40"; char *end = NULL; unsigned int num = strtoul(strNum, &end, 10); // overflows if (errno == ERANGE) { // You've just had a range error errno = 0; } }

What do you mean by this? You use the instruction that does what you want to do.

Nowadays cheap things on internet marketplaces are all white-label, and the "brands" that sell them come and go with the seasons. Even if I did know a good LED strip brand, they might not be getting their lights from the same manufacturer this week, and they're sure as hell not doing any QC. With stuff like this the best you can hope for is to cross your fingers and pray.

100 feet of LED strip lighting is way brighter than a two bulb floor lamp. Even 10 feet would probably be brighter. Of note, if you want a good white light I would suggest RGBW lights, which have an extra white LED just to make white light. RGB lights (and especially low end RGB lights) usually have a pretty noticeable tint to them when trying to make white because the LEDs aren't well matched.

Do you have the WiFi/Bluetooth antennas installed?

Why can't you use Selenium (or other similar browser automation)?

Extension-based ad blockers are widely used and safe. They need access to pretty much everything in your browser to do what they do, but assuming you're running Chrome on Windows every reputable ad blocker is more privacy conscious than the browser and OS you're running them on. If you're still concerned, open source extensions like uBlock Origin or AdGuard provide some security against potential abuse, since anyone could examine the code used to run them. Open source projects are not impervious to malicious behavior, but few are bold enough to provide written record of their misdeeds, and these are projects with a long (in internet time) history of security and privacy.

DNS sinkholes can only block ads coming from a specific domain. YouTube uses the same domain to serve ads and video, so there's no way for a DNS level ad blocker to distinguish between ads and the video you wanted. uBlock Origin is the de-facto ad blocker. Others exist, but uBlock Origin is the most active with the most features for the least money (free) on the most platforms. It's the only ad blocker that would reliably work on YouTube while they were still very actively switching up the ad blocker detection a few months ago.

I will preface this with: I have next to no experience with AutoIt, but lots with other scripting languages. Minor (but catastrophic) issue, you've got an unclosed double quote at the start of the first string, and no quotes at all around the second string. Edit: Not unclosed, just really long. Second one has no quotes though The more relevant problem is you've got the entire control flow of your script wrong. You've placed all the install steps in the way of the main program execution. What your script does right now is it assigns the $reader64 variable, then it immediately starts waiting for the Acrobat Reader DC window to appear, and it never will because nothing got run. Unless you tell it otherwise, the program gets executed top to bottom. It can't know that what you actually want it to do is skip to the end, run the right installer based on the OS (via trying to execute a string with an If... Then... block, which don't believe actually works), only go through the steps for the right installer, then quit. Edit: I misunderstood how you were trying to do this, you were making great big multiline strings and trying to execute them. That would be a valid idea if If... Then... blocks could actually execute strings (and if readerxp had quotes around it), but I think functions are a much better alternative to executing strings, which doesn't appear to be easily possible in AutoIt. You need to restructure your program so that the installation steps don't get in the way of the execution and explicitly separate the steps for each installer, and the way to do that is with functions. I believe something like this would work: ;Require admin so there are no file permission errors. ;2024 #RequireAdmin #include <Process.au3> #include <MsgBoxConstants.au3> If @OSArch = "X64" Then Reader64() ElseIf @OSVersion = "WIN_XP" Then ReaderXP() EndIf Func Reader64() Run(@ScriptDir & "\Adobe Reader\AcroRdrDCx642300620360_en_US.exe") WinWait ("Adobe Acrobat Reader DC (Continuous) - Setup", "Adobe Acrobat is configured to install updates");Wait for the first window. WinActivate ("Adobe Acrobat Reader DC (Continuous) - Setup", "Adobe Acrobat is configured to install updates");Activate the window. ControlClick ("Adobe Acrobat Reader DC (Continuous) - Setup", "Adobe Acrobat is configured to install updates", "Button6");Click Install. WinWait ("Adobe Acrobat Reader DC (Continuous) - Setup", "Setup has successfully installed");Wait for the second window. WinActivate ("Adobe Acrobat Reader DC (Continuous) - Setup", "Setup has successfully installed");Activate the window. ControlClick ("Adobe Acrobat Reader DC (Continuous) - Setup", "Setup has successfully installed", "Button2") EndFunc Func ReaderXP() Run(@ScriptDir & "\Adobe Reader\AdbeRdr11008_en_US.exe") WinWait ("Adobe Reader XI (11.0.08) - Setup", "Ready to Install Adobe Reader");Wait for the first window. WinActivate ("Adobe Reader XI (11.0.08) - Setup", "Ready to Install Adobe Reader");Activate the window. ControlClick ("Adobe Reader XI (11.0.08) - Setup", "Ready to Install Adobe Reader", "Button1");Click next. WinWait ("Adobe Reader XI (11.0.08) - Setup", "Keep your product up-to-date");Wait for the second window. WinActivate ("Adobe Reader XI (11.0.08) - Setup", "Keep your product up-to-date");Activate the window. ControlClick ("Adobe Reader XI (11.0.08) - Setup", "Keep your product up-to-date", "Button8");Do not check for updates. Sleep(1500) ControlClick ("Adobe Reader XI (11.0.08) - Setup", "Keep your product up-to-date", "Button1");Click install. WinWait ("Adobe Reader XI (11.0.08) - Setup", "Setup Completed");Wait for the second window. WinActivate ("Adobe Reader XI (11.0.08) - Setup", "Setup Completed");Activate the window. ControlClick ("Adobe Reader XI (11.0.08) - Setup", "Setup Completed", "Button1"); Click finish. EndFunc

DNS sinks like Pi-hole or AdGuard Home are great at blocking most ads, but they can't block YouTube ads. YouTube ad blocking has to be done with a browser extension (or third party app on mobile).