qbane

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.

If you mean "latest" ECMAScript then that is true. Even latest gcc or clang does not support all features from C++23: https://en.cppreference.com/w/cpp/compiler_support.html.

I am not meant to be harsh, but note that it fails on a small number of test cases, on v0.21 that is ~900 out of ~50k. Strictly speaking it cannot be described as standard-comforming unless there is some reason behind every failed test. A better way to strive on standard conformance, like QuickJS takes, is to pin down the ecma262 revision and make it 100% compliant.

Nitpick: SQL is a programming language. But for most CRUD tasks you should rely less on SQL's programming capabilities until processing information is too expensive outside the SQL server/engine. The advice is also for maintainability.

I prefer the following to ensure the interoperability of external libraries:

`body, html { box-sizing: border-box } * { box-sizing: inherit }`

I reply "..." each time and it works similarly.

Cannot even park a Waymo… Robots are definitely better at this than me

As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.

Then that is a good reason to deny the requests from those IPs