Grepping your own source for variation selectors is the easy part. The problem is nobody's doing that on what they install. A compromised upstream package lands those characters in your node_modules and your CI never looks twice. `npm audit signatures` catches some supply chain stuff but not this. Honestly surprised no package manager has a "scan installed files for suspicious Unicode" step yet.
Readit Newsnulltrace commented on It's time to move your docs in the repo dein.fr/posts/2026-03-13-... · Posted by u/gregdoesit
Not sure I agree with this. MD files need to be constantly synced to code state- why not just grep the code files? This is just more unstructured indexing
Grepping works when you wrote the code. Not so much when someone else installs your package and has no idea which export is public API. We added a one-page markdown saying "use these, ignore the rest" and the wrong-import issues mostly stopped.
nulltrace commented on Bucketsquatting is finally dead onecloudplease.com/blog/b... · Posted by u/boyter
The "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction.
1. You set up an aws bucket with some name (any name whatsoever).
2. You have code that reads and/or writes data to the bucket.
3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.
4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.
5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.
You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.
Seen this happen with Terraform. One team tears down a stack, bucket gets deleted, but another stack still has the name hardcoded in an output. Next CI run uploads artifacts to a bucket name that's now up for grabs. You only notice when deploys start failing. Or worse, succeeding against someone else's bucket.
I've seen something similar across Claude versions.
With 4.0 I'd give it the exact context and even point to where I thought the bug was. It would acknowledge it, then go investigate its own theory anyway and get lost after a few loops. Never came back.
4.5 still wandered, but it could sometimes circle back to the right area after a few rounds.
4.6 still starts from its own angle, but now it usually converges in one or two loops.
So yeah, still not great at taking a hint.
nulltrace commented on Temporal: The 9-year journey to fix time in JavaScript bloomberg.github.io/js-bl... · Posted by u/robpalmer
A big step in the right direction, but I still don't like the API, here's why:
Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.
This is not the case for Temporal objects. Also, the temporal objects have functions on them, which, granted, makes it convenient to use, but a pain to pass it over the wire.
I'd clearly prefer a set of pure functions, into which I can pass data-only temporal objects, quite a bit like date-fns did it.
The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.
nulltrace commented on Practical Guide to Bare Metal C++ arobenko.github.io/bare_m... · Posted by u/ibobev
Do you typically just compile with -fno-rtti -fno-exceptions -nostdlib ?
Last time I did embedded work this was basically all that was required.
Those three flags cover most of it. One gotcha: -fno-exceptions makes `new` return nullptr instead of throwing, so if any library code expects exceptions you get silent corruption. We added -fcheck-new to catch that.
Also -nostdlib means no global constructors run, so static objects with nontrivial ctors need you to call __libc_init_array yourself.
I made a mistake once and signed with wrong keys which then broke DANE. It‘s good to validate your DNSSEC (and DANE, CAA etc.) setup through external monitoring.