I wasn't trying to make any jabs, just an observation that getting outside of your comfort zone can be novel and interesting, even if it's mundane to people that commonly spend lots of time there.
1,458 karma · joined March 19, 2018
https://asahilinux.org/docs/platform/feature-support/m3/#soc...
For example, Sig offered a "voluntary upgrade" to fix the well documented drop safety flaw with the P320, and there's video proof of the same guns going off still in holsters.
Sig is going to be playing whackamole fixing these issues if they ever admit to it, so they won't.
There are also manufacturing issues with intermingling parts with different geometries intended for different calibers and building guns with the wrong parts, such as installing a 10mm Auto/.45 ACP takedown safety level in a 9mm gun, or installing a metal injection molded firing pin safety that's out of spec, worn, or contributes to tolerance stacking in such a way that the gun becomes unsafe.
Fully cocked strikers are ready to ignite a primer if the striker drops. I don't know of another design like Sig's that has a fully cocked striker, which is not to say there isn't one, or that they're all unsafe.
The P320 in particular suffers from compromises shoehorning a fire control unit designed for one gun into another.
Combined with poor manufacturing techniques, tolerance stacking, part mixing, and poor QA, the striker block, which is the last safety intended to block the striker without an explicit trigger pull, can become ineffective.
To answer your question, there's no mechanical reason a handgun cannot be designed an manufactured to not fire without explicit mechanical input from the user. Indeed almost every commercially produced handgun on the market fits this requirement. A combination of failures on Sig's part has allowed this to happen.
Hammer fired guns are capable of doing this safely because they have a sear geometry that requires moving the hammer back against spring pressure with trigger input a very short distance before the hammer drops. Along with a functioning sear block in case the hammer slips off the sear without trigger input, this makes them very safe.
Basically every other striker fired gun on the market uses a semi-cocked striker with a trigger widget and sear block, which is a copy of Glock's design, and it's quite safe.
Sig deviated from this design without fully proving it out. Their guns don't have trigger widgets, which allows the trigger to move under momentum when dropped, causing repeatable firings. The fully cocked striker design leads to a shorter, crisper pull, but a sear slip leads to uncommanded firings, unlike a semi-cocked design, which doesn't have enough energy to fire a primer.
Combine this with poor control of manufacturing, intermingling of parts designed and intended for different calibers, as well as factories in the US and India with varying levels of quality control and poor spec for parts to begin with (metal injection molding for fire control parts), and safety critical systems like the sear block have been shown to not be 100% reliable. It's a system of cascading failures resulting in a firearm that's unsafe to carry loaded.
Sig also won contracts for suppressors, optics, and probably more I'm unaware of or can't remember. Unit cost of the M7 is several times higher than the M4, it's heavier, has more recoil, carries less ammo, and the cartridge it fires is still stopped by commonly available body armor that's manufactured today.
Corruption is obvious in my mind, it's shocking Congress seems either oblivious or so complacent.
I'm less concerned with a little speeding than I am with blowing through lights and stop signs.
As a legitimate open source developer and contributor to buildroot, I've had no recourse besides trying other browsers, networks, and machines, and it's triggered on several combinations.
How exactly do anti-cheat vendors intend to prevent this kind of setup from being effective?
The default should be open and portable APIs, not needlessly furthering a hegemony that is detrimental to us all.
I ask a wide variety of things, from what a given plant is deficient in based on a photo, to wireless throughout optimization (went from 600 Mbps to 944 Mbps in one hour of tuning). I use models for discovering new commands, tools, and workflows, interpreting command output, and learning new keywords for deeper and more rigorous research using more conventional methods. I rubber duck with it, explaining technical problems, my hypotheses, and iterating over experiments until arriving at a solution, creating a log in the process. The model is often wrong, but it's also often right, and used the way I do, it's quickly apparent when it's wrong.
I've used ChatGPT's memory feature to extract questions from previous chats that have already been answered to test the quality and usability of local models like Gemma3, as well as craft new prompts in adjacent topics. Prompts that are high leverage, compact, and designed to trip up models that are underpowered or over quantized. For example:
>> "Why would toggling a GPIO in a tight loop not produce a square wave on the pin?"
> Tests: hardware debounce, GPIO write latency, MMIO vs cache, bus timing.
>> "Why is initrd integrity important for disk encryption with TPM sealing?"
> Tests: early boot, attack surface, initramfs tampering vectors.
>> "Why would a Vulkan compute shader run slower on an iGPU than a CPU?"
> Tests: memory bandwidth vs cache locality, driver maturity, PCIe vs UMA.
>> "Why is async compute ineffective on some GPUs?"
> Tests: queue scheduling, preemption granularity, workload balance.
>> "Why might a PID loop overshoot more when sensor update rate decreases?"
> Tests: delayed ACK, bufferbloat, congestion control tuning.
>> "How can TCP experience high latency even with low packet loss?"
> Tests: delayed ACK, bufferbloat, congestion control tuning.
>> "How can increasing an internal combustion engine's compression ratio improve both torque and efficiency?"
> Tests: thermodynamics, combustion behavior, fuel octane interaction.
>> "How can increasing memory in a server slow it down?"
> Tests: NUMA balancing, page table size, cache dilution.
>> "Why would turning off SMT increase single-threaded performance on some CPUs?"
> Tests: resource contention, L1/L2 pressure, scheduling policy.
One I use with ChatGPT currently is:
> Prioritize substance, clarity, and depth. Challenge all my proposals, designs, and conclusions as hypotheses to be tested. Sharpen follow-up questions for precision, surfacing hidden assumptions, trade offs, and failure modes early. Default to terse, logically structured, information-dense responses unless detailed exploration is required. Skip unnecessary praise unless grounded in evidence. Explicitly acknowledge uncertainty when applicable. Always propose at least one alternative framing. Accept critical debate as normal and preferred. Treat all factual claims as provisional unless cited or clearly justified. Cite when appropriate. Acknowledge when claims rely on inference or incomplete information. Favor accuracy over sounding certain.
Using ollama, hardware acceleration doesn't really work through ROCm. The framework doesn't officially support gfx1151 (Strix Point RDNA 3.5+), though you can override it to fake gfx1150 (Strix Halo, also RDNA 3.5+ and UMA), and it works.
I think I got it to work for smaller models that fit entirely into the preallocated VRAM buffer, but my machine only allows for statically allocating up to 16 GB for the GPU, and where's the fun in that? This is a unified memory architecture chip, I want to be able to run 30+ GB models seamlessly.
It turns out, you can. Just build llama.cpp from source with the Vulkan backend enabled. You can use a 2 GB static VRAM allocation and any additional data spills into GTT which the driver handles mapping into the GPU's address space seamlessly.
You can see a benchmark I performed of a small model on GitHub [0], but I've done up to Gemma3 27b (~21 GB) and other large models with decent performance, and Strix Halo is supposed to have 2-3x the memory bandwidth and compute performance. Even 8b models perform well with the GPU in power saving mode, inside ~8W.
Come to think of it, those results might make a good blog post.
[0] https://github.com/ggml-org/llama.cpp/discussions/10879
Search for "HX 370"
I like this approach of shunting off functionality that's important, necessary, and omnipresent across all OSes to userspace, rather than giving into the temptation to put everything and the kitchen sink into the kernel. It seems to make a more versatile and future proof OS, that's easy to work with in spite of uncertainty.