There's numerous feature flags that seem to just be 'MSRC_[id]' (for the Microsoft Security Response Center), and anecdotally looking through Windows 11 a lot of actual bugfixes (various ReFS driver crashes, for example, have feature flag checks around their fixes) are feature-flagged as per usual with both global (for the whole batch of fixes) and per-feature flags, so this is a bit of an incorrect assumption.

Things breaking downlevel is pretty common anyway, and the emoji picker has been in a pretty bad state since the original picker IME (introduced I believe in RS3, ~2017) was replaced with 'Expressive Input' which also allowed adding GIFs and a few other things but relied on a new UI framework that I suspect was tied to an unrelated internal effort culminating in the '10X' product which only got canceled.. right before Windows 11 development started, and therefore pretty much bitrotted.

Windows 10 was left on a fairly 'bad' release, the 'Iron' semester which was used as a baseline for Server 2022 was still like 10 from a UX perspective (10X was only canceled between that and 'Cobalt', where the Sun Valley work which led to the Windows 11 product happened) but had a fair few bugfixes that didn't get backported to 10 'version 2004' ('Vibranium', I believe, as otherwise the codename would've been 'Chromium' which is bad).

If the full amount of system memory isn't showing on Windows that's likely an unrelated issue you're experiencing (for example with UEFI/BIOS memory mapping mismatching whatever else) and it working on Linux implies that either Linux gets fed different memory layouts or it parses this broken case fine unlike Windows.

If applications aren't using all the memory, and it's also not showing up as cached, that's odd as Windows usually tends to target around 80% of physical memory usage (unless you're really not using that many apps or there's another driver issue going on). Different OSes account for memory usage differently, and there's rarely one single 'memory used' indicator in modern operating systems.

Now I'm running a Turris Omnia with the bundled OpenWRT fork for router tasks and that seems to work fine.

The same legislation that is requiring Apple to allow sideloading also requires other large players (like Meta) to open their communication platforms up to other service or application developers.

In this hypothetical case, there actually would be five competing apps, some even still distributed on the App Store.

On Linux/ext4, it takes an eternity for an enumeration to even start returning results and the entire OS gets stuck on IO while doing so.

I've seen laptop OEMs that rely on a custom kernel driver for this, and then if you want to reimplement their pile of 'overly modular everything control suite' you're stuck loading a generic read/write-memory driver which is blocklisted by every antimalware and anticheat solution in existence.

(In addition, it seems some WMI/CIM/MOF ACPI stuff is supported on Linux fine, too, as long as OEMs try to stick to standard DMTF-spec stuff I guess... so one can also just do 'generic' user-space stuff there if lucky)

> An OS may choose to execute in a virtual addressing mode and, as a result, may prefer to call firmware services provided by UEFI Runtime Drivers in a virtual addressing mode. A UEFI Runtime Driver must not make any assumptions about the type of operating system to be booted, so the driver must always be able to switch from using physical addresses to using virtual addresses if the operating system calls SetVirtualAddressMap().

Disappointingly, it's just a 'plain' case of SMM (which is also, funnily, the main target for ACPI callouts to more 'complex' methods, and on ARM has the very fun equivalent called 'SMC/HVC callouts to EL3/EL2 firmware' although that's supposedly a bit better-defined than Intel SMM) and nothing too clever either - an ACPI method hijacking something to then write to the framebuffer?

Other than that, the writing style here feels almost.. presumptuous and might've been written for the original audience on the site it's posted on, for example I was left wondering things like 'if the author or their friends have access to a machine with this software on it, why don't they dump the firmware flash storage and decompile the actual images, wherever they might be', though it may be they indeed didn't have access to any such hardware or firmware downloads and are just piecing random puzzle parts together, and the post eventually devolved into a general rant against OEM cleverness that I somewhat skipped.

(I'm also mildly torn between 'wow, clever hack' and 'oh lord this would be terrible to diagnose OS boot issues on as you really can't trust OEMs with side effects or long-term maintenance' in this regard)

[1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...

CoD has supported this since their 2019 release, for example.

It is still an interesting cultural observation that here in NL, even people who manually buy a ticket at the driver while struggling using the card terminal do not seem to get an annoyed response inherently even on a half-filled bus, whereas in Germany it seemed almost expected to get chewed out for not having exact change or taking more than 10 seconds to gather a pile of coins - in the pre-app era, of course.

They own the browser. They can theoretically maintain a list of bad origins just as much as they can block an app from the App Store.

Another recent example is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2405... which is for a purely theoretical exploit - not even a PoC - with the only 'sources' being Reddit/Twitter scaremongering, and 'support forum posts' that quote these exact same Twitter threads.