HN user

indutny

911 karma

Just zis guy.

[ my public key: https://keybase.io/indutny; my proof: https://keybase.io/indutny/sigs/xZ05hlJI5Q7vq0EGv-3GVxlxW3TIsoV5PL6lbA9zl74 ]

Posts65
Comments111
View on HN
github.com 4mo ago

Petition to Node.js TSC: No AI Code in Node.js Core

indutny
13pts1
darksi.de 3y ago

Structure of FTS5 Index in SQLite

indutny
2pts0
gradtype.darksi.de 7y ago

Show HN: Person Identification by Keyboard Typing

indutny
202pts80
derivepass.com 7y ago

Show HN: DerivePass – Password Manager that doesn't store passwords in the cloud

indutny
5pts2
darksi.de 7y ago

HashWick V8 Vulnerability

indutny
3pts0
github.com 9y ago

Show HN: CommonJS Tree Shaker Plugin for Webpack

indutny
4pts0
indutny.github.io 9y ago

Show HN: Proof-of-Work Vote counter widget

indutny
1pts1
indutny.github.io 9y ago

Show HN: Proof-of-Work vote counter widget

indutny
5pts0
indutny.github.io 9y ago

Show HN: Entropic Poetry – Translate private keys to poetry

indutny
2pts0
derivepass.com 9y ago

DerivePass – Password manager that doesn't store passwords

indutny
2pts0
itunes.apple.com 9y ago

Show HN: DerivePass – Emoji Password Manager

indutny
2pts1
darksi.de 9y ago

Google V8 hash seed timing attack

indutny
3pts0
derivepass.com 9y ago

DerivePass (Emoji Password Manager) – Beta Signup

indutny
1pts0
darksi.de 9y ago

uv_link_t – libuv pipeline

indutny
1pts0
gypkg.io 10y ago

GYP-based package manager

indutny
3pts3
github.com 10y ago

Extended verification for Git tags

indutny
2pts0
indutny.github.io 10y ago

Kerning Clock

indutny
3pts0
hackcha.in 10y ago

Show HN: Hackchain – Continuous Bitcoin-Inspired CTF Competition

indutny
83pts4
github.com 10y ago

More creative fake Satoshi's signatures

indutny
1pts0
github.com 10y ago

Llnode – lldb plugin for live/postmortem Node.js

indutny
2pts0
darksi.de 10y ago

Sea of Nodes

indutny
14pts0
darksi.de 10y ago

Sea of Nodes

indutny
1pts0
github.com 11y ago

Bud – A TLS terminating proxy

indutny
42pts16
github.com 11y ago

Dumb and verifiable scrypt implementation

indutny
3pts0
indutny.github.io 11y ago

RSA Certificate Map

indutny
35pts15
blog.indutny.com 11y ago

Deoptimize me not, V8

indutny
1pts0
github.com 11y ago

Show HN: Caine – A GitHub bot

indutny
48pts6
indutny.github.io 11y ago

Show HN: Generate self-signed certs in browser

indutny
13pts2
news.ycombinator.com 12y ago

Ask HN: Why does Quantum Entanglement need to exist?

indutny
2pts1
github.com 12y ago

Bud – TLS-terminating load-balancer

indutny
2pts0

The real risk with LLM-generated code is that it looks plausible but hasn't gone through the same level of scrutiny. It passes a quick review because it reads well, but edge cases get missed.

Precisely! Because the code is made to believable the risk of accepting it without understanding full implications is very high.

If the answer is "the same review process we've always had" then the problem isn't AI, it's whether that process is rigorous enough for the stakes involved.

True, but there is also a reputational component to how changes are reviewed (whether we like it or not). The longer the tenure and the deeper the understanding of the changed code is - the chance of careless Pull Request gets lower.

I appreciate hearing your point of view on this. In my opinion the future of Open Source and AI assisted coding is a much bigger issue, and different people have different levels of confidence in both positive and negative outcomes of LLM impact on our industry.

It is great to have a legal perspective on compliance of LLM generated code with DCO terms, and I feel safer knowing that at least it doesn't expose Node.js to legal risk. However it doesn't address the well known unresolved ethical concerns over the sourcing of the code produced by LLM tooling.

The submitted code must adhere to either of (a), (b), (c), and separately a (d) clause of: https://github.com/nodejs/node/blob/main/CONTRIBUTING.md#dev...

If submitter picks (a) they assert that they wrote the code themselves and have right to submit it under project's license. If (b) the code was taken from another place with clear license terms compatible with the project's license. If (c) contribution was written by someone else who asserted (a) or (b) and is submitted without changes.

Since LLM generated output is based on public code, but lacks attribution and the license of the original it is not possible to pick (b). (a) and (c) cannot be picked based on the submitter disclaimer in the PR body.

As someone who was a part of the aforementioned security team I'm not sure I'd be interested in reviewing such volume of machine generated code, expecting trap at every corner. The implicit assumption that I observed at many OSS projects I've been involved with is that first time contributions are rarely accepted if they are too large in volume, and "core contributor" designation exists to signal "I put effort into this code, stand by it, and respect everyone's time in reviewing it". The PR in the post violates this social contract.

Taking the question of whether this would be a useful addition to Node.js core or aside, it must be noted that this 19k LoC PR was mostly generated by Claude Code and manually reviewed by the submitter which in my opinion is against the spirit of the project and directly violates the terms of Developer's Certificate of Origin set in the project's CONTRIBUTING.md

As a shameless plug I'd like to suggest the project that I have been using for my personal credentials for quite some years now: https://derivepass.com/ . The encrypted website metadata is stored only locally (with only optional remote sync, and even that has to be your own server), and the passwords are not stored at all (they are generated from your master password).

Fantastic material! That being said I'd recommend to have several alternative textbooks for every subject at hand. Whenever stuck - one should switch to another and try a different take.

I think photon self-interaction might be thought of as a confirmation of photon's existence. Particle ontology is a tough question, but I don't think there is a reason to exclude photon from the list without excluding all other particles.

In this image: https://advances.sciencemag.org/content/advances/5/7/eaaw256... they describe their apparatus.

The light comes from bottom left, then gets into Beam Splitter (BS) and splits in two. The top-left detector has a pre-selected filter and a measurement device after a delay line. As far as I understand, this device gives binary output: either light received or not. The top-right detector captures whole image of the light ray, but does so only if the left detector has seen light.

The result is that the image from the top-right detector is highly correlated with the pre-selected filter of the top-left detector, even though they're placed in different arms of Beam Splitter! https://advances.sciencemag.org/content/advances/5/7/eaaw256...

Very interesting! I don't think that I ever had a sample from a non-standard keyboard layout in the dataset.

While it might sound like this should make your samples very different from others, it could actually act the other way and confuse the network. Hopefully, this will be improved in the next version of it, which I'll start training right after this data collection sprint.