Hacker News: brigade

New comment by brigade in "Apple and a Hacker's Future"

brigade — Mon, 05 Oct 2026 17:11:37 +0000

If you're arguing that SIP isn't a useful defense against malware, I agree there.

Sandboxing full disk reads is orthogonal to what SIP actually provides. It's entirely possible for an unsandboxed binary to slurp your private data even with SIP enabled.

New comment by brigade in "Apple and a Hacker's Future"

brigade — Mon, 05 Oct 2026 16:40:59 +0000

Protection from the sort of malware OP was hit with is the most commonly cited dire warning against disabling SIP. I just assumed that was also the reason you were against disabling SIP in order to grant permissions to software you intentionally installed.

New comment by brigade in "Apple and a Hacker's Future"

brigade — Mon, 05 Oct 2026 15:21:39 +0000

Sort of; SIP originally was simply meant to protect /System from root. But nowadays, it's more used for system attestation. Which in turn is used by the OS to decide how to ask for and enforce certain user permissions and sandbox profiles.

New comment by brigade in "Apple and a hacker's future"

brigade — Mon, 05 Oct 2026 14:36:30 +0000

Which system integrity protection are you worried about missing? Muse being able to exfiltrate the contents of your messages db doesn’t compromise system integrity to begin with. It being able to write arguably does, but this whole conversation was about how to grant it full disk access in the future anyway.

And OP had SIP enabled, but his system still got compromised with a remote exploit.

New comment by brigade in "Apple and a hacker's future"

brigade — Mon, 05 Oct 2026 13:03:13 +0000

Or the scary warnings today against disabling SIP, repeated by forum users anywhere it’s discussed.

Which happens to be the only way to disable the TCC permission dialogs OP complains about. Guess the warnings worked well enough that no one knows that anymore.

New comment by brigade in "Unsurprisingly, Meta's new Muse AI agent blatantly ignores users permissions"

brigade — Tue, 29 Sep 2026 15:27:39 +0000

App store apps are required to run in a sandbox that denies file accesses without user permission.

Muse is not available in the macOS app store. Almost certainly because of the sandboxing requirements.

New comment by brigade in "The case against JPEG XL"

brigade — Mon, 14 Sep 2026 03:11:24 +0000

Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.

Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.

New comment by brigade in "The case against JPEG XL"

brigade — Mon, 14 Sep 2026 02:36:32 +0000

You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.

Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.

New comment by brigade in "LG denies TV spying claims, says tracking and snooping concerns 'not true'"

brigade — Sat, 12 Sep 2026 19:31:16 +0000

For like a decade, the "opt-in" to ACR was included in the ToS agreement needed to use any smart features. Then at least some brands made the opt-in separate, but made it look like a recommendation engine or "help us improve your experience" agreement.

LG adopted the "Maybe Later" dark pattern for opt-in to ACR, at least in some markets. Though I guess you never know for sure with A/B testing.

New comment by brigade in "Xiaomi: New CPU matches Apple cores single threaded, much faster multithreaded"

brigade — Mon, 24 Aug 2026 15:59:51 +0000

All 10 cores support the same extensions. It’s silly to implement an SoC any other way, and it’s been a decade since someone has last made that mistake.

New comment by brigade in "A third world engineer responds to “RISC-V: They should have known better”"

brigade — Mon, 17 Aug 2026 00:17:10 +0000

Well the original article is also about RISC-V isn't a great ISA for embedded either, and how that's supremely disappointing because there's no inherent reason why the designers couldn't have learned from decades of ISA research and made it suck even a little less. OP doesn't even defend the ISA committee (unlike HN, somehow...)

As much as people complain about warts in other ISAs like x86, their design decisions made sense back when they were made (or at least, no one really knew better)

New comment by brigade in "Dav2d"

brigade — Sat, 02 May 2026 20:27:41 +0000

There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.

New comment by brigade in "Networking changes coming in macOS 27"

brigade — Mon, 27 Apr 2026 17:59:56 +0000

Still true for extended attributes, which Finder and Spotlight love to query.

New comment by brigade in "USB Cheat Sheet (2022)"

brigade — Sun, 26 Apr 2026 01:27:18 +0000

Even backwards compatibility is optional in USB4. There are USB4 devices (SSDs at least) that will not function when connected to USB 3 ports.

New comment by brigade in "XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?"

brigade — Wed, 22 Apr 2026 08:17:37 +0000

Zero micro ops to be precise, that’s handled entirely at the register rename stage with no data movement.

New comment by brigade in "XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?"

brigade — Wed, 22 Apr 2026 08:06:55 +0000

Cortex A8 vsub reads the second source register a cycle earlier than veor, so that can add one cycle latency

Not scalar, but still sub vs xor. Though you’d use vmov immediate for zeroing anyway.

New comment by brigade in "New Apple Silicon M4 and M5 HiDPI Limitation on 4K External Displays"

brigade — Mon, 30 Mar 2026 08:39:04 +0000

Fine, you made me look it up. M1 Air defaults to 2880x1800 on a 2560x1600 display, which is a 1.125x scaling. Nowhere near the 1.5x you claim.

New comment by brigade in "New Apple Silicon M4 and M5 HiDPI Limitation on 4K External Displays"

brigade — Mon, 30 Mar 2026 07:16:23 +0000

Apple never supersamples by 2x. Default MacBook Air scaling was around 1.1x iirc.

New comment by brigade in "New Apple Silicon M4 and M5 HiDPI Limitation on 4K External Displays"

brigade — Mon, 30 Mar 2026 06:38:12 +0000

OP dances around the key context that this isn’t hidpi, but rather a 3rd party hack that uses hidpi rendering to supersample their “native” 4k resolution by 2x, since the end result looks more pleasing to them than the native 4k render.

New comment by brigade in "ICAO issued new power bank restriction on flight"

brigade — Sun, 29 Mar 2026 00:05:32 +0000

And that itself is a recent policy change from just in the last two months; as of January United's official policy [1] matched the FAA's in only requiring checked devices to be powered down

[1] https://web.archive.org/web/20260129152627/https://www.unite...