qbane

I pondered for a while, it IS the company I used to know

LLMs are as good as almost any security researcher, and anyone can run them.

I wonder what the metrics are. Also, not "anyone", just the affordable.

You could, but by targeting a specific Electron app the mindset would be much simpler. Just take a look of how many times does the dev behind VS Code decide to upgrade their Electron/Node.js version, and how many breakages due to them.

It is all about unknown unknowns.

I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.

I wish Google can bring back the OG Pixelbook, where "AI" merely means Google Assistant.

I realized that my mentioning UUID without v4 was misleading.

Okay, sightly more bits than UUID v4. The whole article is merely reasoning "why at least 128 bits are required", and if you smuggle some non-random data inside these bits the entropy can only drop, making it more vulnerable to collision, i.e. inferior to UUID v4.

Note that when neither is supplied, the text mode is the default. This is why I said that it is the C library handling the "b" flag.

tl;dr we reinvented UUID and it works well

It's C library taking care of the "b" part for you according to the article.

There is even a table copy-pasted into a paragraph without noticing.

What’s needed is something different:

Requirement ptrace seccomp eBPF Binary rewrite Low overhead per syscall No (~10-20µs) Yes Yes Yes [...]

null hypothesis bot

Reminding me of the Shoelace [0] project, which was rebranded as Web Awesome. The original (v2) repository was then archived.

[0] https://shoelace.style/

The watch is interactive! Nice detail

Productivity is finite. If you pivot entirely to the AI stack, you're going to lose bandwidth for everything else. It's an opportunity cost problem.

A better example would be to use LLMs to generate passwords or secret keys. Then even if it looks random to human, the inherent bias would make it a security disaster.

You can still obfuscate JS heavily and make a VM that executes also obfuscated code calling arbitrary browser APIs. At least In WASM everything is sandboxed so the attack surface is smaller.

cf. Kagi is a good take

Remember: It is a company that keep saying how much production code can be written by AI in xx years, but at the same time recruiting new engineers.

The "source" link at the footer seems to point to the author's GitHub profile, not source repository. The repo under it contains no code either.

I read Effective Modern C++ years ago and was confused exactly like what you describe.

icc's result is interesting too

Just started making my own recently with CodeMirror 6 during holidays. No saving function for now: https://qbane.github.io/cgm

Not likely:

It only supports a subset of Javascript close to ES5 [...]

I have not read the code of the solver, but solving YouTube's JS challenge is so demanding that the team behind yt-dlp ditched their JS emulator written in Python.

To declare "open source", you have to provide a way for the public to get access to the source code. But there seems to be none at least for the time being.

That is a fair assessment. Maintaining read/write pos and peek them at every operation is a big performance hit. The impact is amplified if each invocation needs a syscall. That is exactly what futexes address: Allowing spin locks to remain in user space and avoid entering the kernel as long as contention is low.

In JavaScript, atomic operations are relatively lightweight, so their overhead is likely acceptable. Given that, I am open to adjusting my code to your suggested approach and seeing how it performs in practice.

By a quick glance, yes, this is what I want: a channel to communicate between processes via a piece of shared memory, protected by a pair of futexes.

In JS ecosystem, buffers that allow data loss is more common (aka ring buffers), but ringbuf.js [1] is the only complete implementation to my knowledge. In my use case on I/O between WASM modules where data must be transferred as-is, the process must block on buffer overrun/underrun in a synchronous manner. Therefore a circular buffer is required. I could not find such a niche library written in JS, so I decided to bite the bullet and reinvent the wheel [2].

[1] https://github.com/padenot/ringbuf.js

[2] https://github.com/andy0130tw/spsc

I wrote my first SPSC circular buffer implementation in TS upon reading the previous post on futex [0] from the same author. It was more intricate than it had seemed, until I finally sat down and wrote my own code.

[0] https://h4x0r.org/futex/ discussion: https://news.ycombinator.com/item?id=44951563

`--ignore-scripts` should be the default behavior.

I really appreciate the clear and detailed project description, the only concern is the title on HN. Failing on tests is fine, especially when it demands huge efforts to triage and reiterate on the project structure for them.