Hacker News: johnisgood

New comment by johnisgood in "Phoenix LiveView 1.2 Released"

johnisgood — Sun, 14 Jun 2026 09:33:11 +0000

They were pretty good a year ago, so I am sure it is even better than that now.

New comment by johnisgood in "FPS.cob: A first person shooter in COBOL"

johnisgood — Thu, 11 Jun 2026 18:02:09 +0000

I have many projects with 0 commits, meaning were I to use git, it would be a single commit. It does not mean anything.

New comment by johnisgood in "Grit: Rewriting Git in Rust with agents"

johnisgood — Wed, 10 Jun 2026 16:44:06 +0000

Yeah, pretty much. :)

New comment by johnisgood in "Grit: Rewriting Git in Rust with agents"

johnisgood — Wed, 10 Jun 2026 14:28:05 +0000

I removed it but I added that I hate these people. :P So yeah, it pisses me off, too.

New comment by johnisgood in "Grit: Rewriting Git in Rust with agents"

johnisgood — Wed, 10 Jun 2026 13:16:04 +0000

GPL makes sure that the code remains open. Seems like these new gen devs are against open source.

New comment by johnisgood in "Claude Fable 5"

johnisgood — Wed, 10 Jun 2026 07:28:54 +0000

Yes, these are gut feelings. That said, I have lots of experiences with Opus and I have lots of projects and contributions (all reviewed and tested) made with the help of it. Definitely useful, to me and to people whose project matters to them. :P

Adding "do not make mistakes" is silly, in my opinion. There is always a good chance it will make mistakes. You should rather be more specific about a thing rather than as broad as "do not make mistakes" is. It just does not work that way.

New comment by johnisgood in "Microsoft's open source tools were hacked to steal passwords of AI developers"

johnisgood — Wed, 10 Jun 2026 07:26:13 +0000

I do agree.

New comment by johnisgood in "Microsoft's open source tools were hacked to steal passwords of AI developers"

johnisgood — Tue, 09 Jun 2026 20:28:41 +0000

I think that the numerical example you gave appears to be wrong unless you intended 1% rather than 0.01%.

In any case, fair enough. The concern is that organizations will build processes around AI where many people do not review outputs carefully. I do not disagree with this.

I also agree that my particular workflow is anecdotal and does not work at scale.

New comment by johnisgood in "Claude Fable 5"

johnisgood — Tue, 09 Jun 2026 20:21:53 +0000

I have found many mode of failures with Opus during some task related to writing letters (not legal), and I actually put it into the memory and it works more or less for these specific tasks. For example when I want it to draft something, it always ends up being so flat, yet when it explains them to me, it is usually really great but not when I am telling it to put it in the draft. Adding these to memories with the help of Opus ended up resulting in a much better experience. There are still some blind spots but I also figured out how to make it give me the charitable version, without less protection, so I do not have to now go back and forth it.

New comment by johnisgood in "Microsoft's open source tools were hacked to steal passwords of AI developers"

johnisgood — Tue, 09 Jun 2026 13:23:23 +0000

If I vibe code a project, that involves docs and tests as well. Obviously I do not, at any point, do anything blindly and there are some iterations for everything. I always double-check, and I do not use "agents", I do everything manually. I always check what the LLM is thinking, in real-time. I might be old school, but that allows me to write code that is not a pile of shit. :P I am still conscious about quality.

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 10:40:47 +0000

I really was just commenting on the "Only libc is dynamically linked" bit. But yeah, there are cons and pros of dynamic vs static. :)

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 10:39:04 +0000

Yeah, seems like everything just seems minimal, but not actually is.

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 08:28:02 +0000

If the binary still depends on libc.so.6 (glibc) at runtime, then it is not a fully static binary (read: not a static binary). It is a dynamically linked executable, albeit one where most non-libc dependencies have been statically linked.

I am not going to pretend I know Rust enough to comment (yes, would be a minute check), I was just commenting on the "Only libc is dynamically linked" bit.

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 07:11:47 +0000

Off: I thought I am becoming dumb, but this really puts me in a new perspective. The odd thing is that even people who work in IT hold similar beliefs. I am not entirely sure what is going on. Favoring a language so blindly seems like a thing, apparently? For example they seem to have convinced themselves that Rust is "safe" if you use it for anything (without implementing the security features) because it is (memory) safe? I did not imagine beginners would make such a mistake either, but alas.

I noticed your comment is getting downvoted. I wish I knew why though. Is it because of your analogy? Is it because they think that somehow "single binary" has anything to do with the programming language? Would like to know. I am not going to assume that it is a confirmation of what I wrote earlier.

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 07:02:59 +0000

No, it does not depend. Your parent is correct with his analogy.

Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.

New comment by johnisgood in "Show HN: Gitdot – a better GitHub. Open-source, written in Rust"

johnisgood — Tue, 09 Jun 2026 07:01:04 +0000

Yeah, this is what the people who have parroted "Rust is safe" have achieved. Rust is not "safe" in the broader sense of the word, only "memory safe". You have to implement the security yourself!

New comment by johnisgood in "Show HN: Gitdot – A better GitHub. Open-source, written in Rust"

johnisgood — Mon, 08 Jun 2026 23:00:49 +0000

I agree. I like the website, looks minimal, but minimalism is not reflected in the stack.

New comment by johnisgood in "Hallucinate – Massively Multiplayer Online Rave"

johnisgood — Thu, 28 May 2026 10:51:38 +0000

Same... I am left handed and I use the mouse with my right hand, and WASD would have been much more ergonomic.

New comment by johnisgood in "We've raised $17M to build what comes after Git"

johnisgood — Sat, 11 Apr 2026 02:03:54 +0000

I like darcs, so I am rooting for pijul.

https://pijul.com

New comment by johnisgood in "AI assistance when contributing to the Linux kernel"

johnisgood — Sat, 11 Apr 2026 00:55:32 +0000

You have shifted from "very easy not to infringe" to "don't infringe frequently", which concedes the original point that humans can and do produce infringing code without intent.

On independent creation: you are conflating the tool with the user. The defense applies to whether the developer had access to the copyrighted work, not whether their tools did. A developer using an LLM did not access the training set directly, they used a synthesis tool. By your logic, any developer who has read GPL code on GitHub should lose independent creation defense because they have "demonstrated capability to produce code directly from" their memory.

LLM memorization/regurgitation is a documented failure mode, not normal operation (nor typical case). Training set contamination happens, but it is rare and considered a bug. Humans also occasionally reproduce code from memory: we do not deny them independent creation defense wholesale because of that capability!

In any case, the legal question is not settled, but the argument that LLM-assisted code categorically cannot qualify for independent creation defense creates a double standard that human-written code does not face.