This is admittedly an aside from the content of the post itself, but... why do so many mobile sites insist on preventing zooming in and seem to share the same incredibly buggy image zooming? It's quite frustrating.
The number of critical CVEs every year related to memory safety seems to point to the contrary. The amount of "just one more static analysizer and we'll never have any bugs!" in the C++ community is honestly disturbing, alongside the obvious elitism and absurdity of statements like 20 years of knowledge == no bugs ever.
Steganography fundamentally requires you to be able to know where the data is, which requires you to have the original image to compare against. The only other strategy I'm aware of is setting known pixel positions to exact data, which is very easy for basic tools to spot and decode. Or to add the data to non-visual data blocks if the image format supports those, which is also quite easy to spot.
Although it would be much more exciting to have some world conspiracy, try to consider what that would mean. That conspiracy's so powerful it can singularly decide votes across a union of dozens of countries, and yet still feels the need to enact a law to invoke that power in the first place.
No, this is a much more benign form of government overreach, one born out of a normal desire to suppress citizens, and perhaps a healthy amount of regulatory capture by large corporations.
Such systems are unfortunately trivially defeated by, for example, adding rings of colourful blocks around the edges of the image. If the scanning systems are then updated to notice rings around the image, bad actors will start cutting images in half and adding the colours there, etc. It's a never-ending arms race that's bound to leave regular people worse off.
> I wonder if you're confusing statements of fact, for attacks?
Hearsay and gossip from the "juicy grape vine" along with implying Jarred is too stupid to critically think about his own path in life because he didn't go to university are not exactly statements of fact. They're elitist and vindictive, but those are not synonymous with honest.
> If that was your read, I think you're taking more from sources that aren't this post.
I'd encourage you to reread the post and try to catch how weirdly spiteful and inconsistent it sounds in places:
> But having graduated from the Thiel Fellowship school of thought rather than university...
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective.
> Jarred was already writing slop well before he had access to LLMs.
> Now, it's not our business to police what our users do... We made futile attempts to guide them towards better programming practices.
How is it kind to imply that by not going to university, Jarred was too stupid to think critically about his own path in life? Or just this in its entirety: "Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective."
We have very different ideas about what kindness looks like. Honesty and rudeness are not synonyms.
The argument isn't to avoid calling out "bad" behaviour, it's that you can do so with a professional (or at least not actively childish) tone. Using phrases like "stinky manager" while taking multiple jabs at Jarred's personal and educational background (implying by not going to university he was too stupid to think critically about his path forward) paints a weirdly childish yet elitist viewpoint. The blog post reads as vindictive, akin to something along the lines of "screw you kid, glad to be rid of you, and thanks for the $120,000 btw."
I don't interact with Zig or Bun, but I certainly haven't been enticed to try Zig after this.
Unfortunately all of the major AI model providers are massively incentivized to fit their models to various political narratives, especially through historical denialism. The "diverse 1940s German soldiers" debacle from Google comes to mind, or perhaps "nothing of note happened at Tiananmen Square" from any of the Chinese models.
Just wanted to say I'm impressed with the speed of progress! There's clearly a lot of passion being poured into the project, and I appreciate that folks are responding really quickly to things. It looks like you've already fixed most/all of the things I noticed, and added Firefox to the test suite[0]. Nice!
How much of this is vibe coded? The widget demos about halfway down seem half-baked; the currency input allows letters and letter inputs visually disappear when you unfocus it. The calendar input appears to select the day before the one I clicked. The markdown editor places hashes after the text on the current line rather than making the current line a header. The dropdown search doesn't seem to work (typing "R" shows React and AngulaR, but typing "Re" doesn't show any options).
All of those are fixable of course, and the idea is neat! It's just a bit of a rough showcase, at least on Firefox.
Apple is also an absolutely enormous company. Even if Valve wanted to lock in prices, they're simply too small for RAM manufacturers to notice on their radar, unfortunately.
That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap.
How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.
Is this at all coherent...? The author really seems to be comparing cookies to JWTs as if they exist in the same category, but it really is apples to oranges here. In fact, one of the first articles they link to spell that out explicitly:
> A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens.
And yet the author seems not to have noticed, or something? Odd.