ntauthority

there's an actual sku of one lenovo handheld that officially runs SteamOS, i assume that's what GP is referring to

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.

They left the community shortly after, likely in part fueled by the way an abuser got their GitHub account destroyed while the abuser pretty much remained unscathed.

(and 'impossible using normal GUI/CLI tooling' seems unlikely, for one as regedit is still 'normal tooling' as well, and secondly because I've yet to come across a service that can't be disabled with the 'sc' command line utility, discounting Windows Defender though that is rather a special case due to the chance of malware itself disabling it, so it has a very specific series of steps to first disable the tamper protection in a trusted way and only then disable the service)

In this case it seems like an environment-specific issue, as if everyone would have this specific thing be broken, it'd probably long be noticed and fixed. In fact, one could probably easily find out what is wrong using a profiling session with WPR/WPA as the main symptom here is 'uses 100% of a CPU core', a methodology recently most famously spread by Google's Bruce Dawson.

(similarly, I wonder if these same people would 'complain' a Linux distro upgrade would affect their edits to /lib/systemd/system/*.service files - I would somewhat presume that to not be the case, in fact)

As an opposite example, here's a Wine bug report of a Windows application failing to work in some network environments, but only if it in any way touches the Linux networking stack (such as using VirtualBox's soft NAT, or if running under Wine): https://bugs.winehq.org/show_bug.cgi?id=53346

I guess, in general, software (and networking) is 'bonkers'.

It is a bit more nuanced than this. Qualcomm ships a giant custom (mandatory, most the platform will not even work without it!) driver stack on Windows and uses ACPI definitions more than most x86 platform vendors, to the extent that it even exposed a bug in the Windows ACPI implementation when an ACPI method return buffer would exceed 64 kB so since this generation of SoC a lot of the Windows drivers instead bundle their own 'subset' of certain ACPI buffers and the main DSDT is empty as a result.

Linux on ARM still doesn't really use ACPI except where forces more influential than Qualcomm managed (e.g. SBSA?) so even downstream Linux kernels for Qualcomm still use DT.