csmantle

Previously: <https://news.ycombinator.com/item?id=48131847>

Besides, the commit history[0] also looks very special:

- 1a0a9b3e9831d9bdbc9d8eba601aa2fa5e9d2708: 4

- 277d6c85c8fd27581c245940e91a40ad2a9114da: may26-3

- 2d2e56ab6228b4814b4a0bc06864e46a68bb40ea: may26-2

...

- d5c117af131c6140f08325882f6b368d91ab6ae8: May 20 2026 - 1

- 715d5250e4bb65cecc7a5c4aa082fc95b717c449 (root): ironwall compiler

[0] https://github.com/3WyUFvDOdCbBw7gOZHwcfgKF/ironwall/commits...

the maintainer didn't catch that

They actually did notice something in <https://github.com/jqwik-team/jqwik/issues/708#issuecomment-...>:

One short request before I go into details. Could you disclose on whose behalf you're discussing this? Just personal interest is fine, I just want to make sure that I'm not spending my time with some AI-driven company, let alone an LLM-controlled agent.

I first read this from the author's posting to oss-security. Turns out that the author did agree to revise the blog post for the "admin cap for root shell" part [^0]. [^1] would probably tell more.

The title looks like clickbait to me.

[^0]: https://www.openwall.com/lists/oss-security/2026/05/08/10

[^1]: https://www.openwall.com/lists/oss-security/2026/05/08/14

The PR author didn't even bother to properly capitalize their subject and add a description. What a double standard for code quality Macroslop is applying to internal vs. external contributions.

The industry's goal is to ship fast and profitably. A learner's goal isn't.

This resembles some serverless pastebins. Data is serialized into the fragment part, and client-side JS deserializes them. The only practical difference is that this app sets them as HTML while those set them as text.

IIRC Mozilla usually categorize internally-found bugs into a few large CVE IDs, grouped by severity, with around ten or so bugs in each. Every advisory gets several CVEs of this kind, for example, <https://www.mozilla.org/en-US/security/advisories/mfsa2026-2...>, <https://www.mozilla.org/en-US/security/advisories/mfsa2026-1...>, <https://www.mozilla.org/en-US/security/advisories/mfsa2026-0...>, etc.

So, cyber security of tomorrow will not be like proof of work in the sense of "more GPU wins"; instead, better models, and faster access to such models, will win.

It's not proof of work, but proof of financial capacity.

The big companies are turning the access to high-quality token generators (through their service) into means of production. We're all going direct to Utopia, we're all going direct the other way.

`jj new` works like `git checkout` most by creating an empty revision on the top. `jj edit` on the other hand resembles `git checkout; [edits...]; git add -A; git commit --amend --no-edit`.

I failed to see why this would be something that "comes after Git" from a VCS perspective.

The line-based diff(1)/diff3(1)/patch(1) kit often works, and that mindset thrives and gets carried till today. Many toolkits and utilities have been designed to make it more ergonomic, and they are good. Jujutsu is an example. We also have different theories and implementations, some even more algebraically sound like Darcs and Pijul.

But GitHub the Platform is another story, given that they struggled to achieve 90% availability these days.

This Is Seven as a Service.

Another important aspect is that, without an external library like `wabt`, I can't just open Notepad, write some inline WASM/WAT in HTML and preview it in a browser, in the same way that HTML+CSS+JS works. Having to obtain a full working toolchain is not very friendly for quick prototyping and demonstrative needs.

If all the app need is to upload a photo of PCB, <input type="file"> is more than sufficient. It's been baseline years ago.

For download, it can download from a blob URI. This is not an uncommon practice.

If (not verified since I'm using Firefox) it claims that "Gerber files are composed of many individual files so that those two don't suffice" and the app does involve Gerber processing, it could have been solved by introducing a zip library.

This reminded me of <https://xkcd.com/2893/>.

Related threads:

* https://github.com/orgs/community/discussions/188156 ("[2026-02-27] Incident Thread")

* https://github.com/orgs/community/discussions/188151 ("Having trouble finding & showing repository's wiki page with non-ASCII page title")

* https://github.com/orgs/community/discussions/188152 ("Broken UI and 404 to files and directories with non-ASCII names")

Related: <https://t2linux.com/#news-2026-02-14>

This is just so hilarious. They'll eventually have to add "man man" to the list.

I could recompile it but compiling firefox is a pain in the ...

Would second this. Mach uses Python, and the dependencies they use are a pain whenever no pre-built wheels are available. Especially so when you see that an "optional" Mach dependency for build system telemetry is what busting the configuration (not build) stage...

I think we can look forward to running this on more non-Chrome browsers once @function [0] gets wider support?

[0] https://caniuse.com/wf-function

Header-only libs can help avoiding the troubles and complexity of linker setup. This might be even more important on Windows, which this lib "explicitly support".

Wow. LLMs can really imitate human sarcasm and personal attacking well, sometimes exceeding our own ability in doing so.

Of course, there must be some human to take responsibilities for their bots.

If you are referring to timestamps, buildids, comptime environments, hardwired heuristics for optimization, or even bugs in compilers -- those are not the same kind of non-determinism as in LLMs. The former ones can be mitigated by long-standing practices of reproducible builds, while the latter is intrinsic to LLMs if they are meant to be more useful than a voice recorder.

It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.

Methodology is one thing; I can't really agree that deploying an LLM to do sums is great. Almost as hilarious as asking "What's moon plus sun?"

But phenomenon is another thing. Apple's numerical APIs are producing inconsistent results on a minority of devices. This is something worth Apple's attention.

Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.

The devs should really setup a client-only GitHub Pages for an accessible demo. Judging from skimming the project itself, it's definitely doable without locking into their platform.

AI?

Probably not; this point is well justified by both theory and practice. Supporting suitably larger operands is indeed what naturally comes following the increase of computation demands.

One point I do differ from the author is that register width don't necessarily correlate with the size of address space. Even 8bit machines can address a large space by splitting apart the logical address and using multiple registers. Likewise, having a wide register does not imply the same address width.

You can find more of these kinds of optimizations on SpacemiT’s blog post.

The linked article (<https://www.spacemit.com/news/%e8%bf%9b%e8%bf%ad%e6%97%b6%e7...>, in Chinese however) is definitely worth reading. Glad to have so much to learn about instruction selection!

Python's main distinction from a shell scripting language is that external program invocations are not first-class citizen. Also no easy ways to feed/read the subprocess's std io.