johnisgood

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.

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.

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

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

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.

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.

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.

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!

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

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

I like darcs, so I am rooting for pijul.

https://pijul.com

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.

It is unnecessary, and it was an obvious offense, not defense. Of course it is "bad". We (Trump) need(s) to stop creating wars and fucking up the economy, while killing others. It is bad all the way down.

> Right now it's very easy not to infringe on copyrighted code if you write the code yourself.

Humans routinely produce code similar to or identical to existing copyrighted code without direct copying.

Yeah, there is no way they need $1M for the servers, come on...

I do not understand the fixation on authentication/signatures. They have different threat characteristics:

You cannot retroactively forge historical authentication sessions, and future forgery ability does not compromise past data, and it only matters for long-lived signed artifacts (certificates, legal documents, etc.), yet the thread apparently keeps pivoting to signature deployment complexity?

I do not get it.

Now give an excuse for pushing so hard for docker on FreeBSD.

Most of their issues have been solved a long time ago, with 1000x less code. It is depressing at this point. I really had no clue IT was in the shitters this much. I knew it was theatrical but I had no idea that it was by this much.

Indeed a sad state of affairs.

All of them are really, REALLY bad.

Please read the LLM output critically instead of doubling down on it.

Your defense-in-depth framing makes no sense. If .git/config or similar mechanisms are the attack vector, then adding more editor safeguards would be treating a symptom, as the real problem is git's trust model. The "users don't think about git when using editors" argument also proves too much. Many users also do not think about PATH, shell configs, dynamic linker, or their font renderer either, but you cannot make editors bulletproof against all transitive dependencies...

Seriously, it is actually backwards. Git is where the defense belongs, not every downstream tool that happens to invoke git. Asking editors to sandbox git's behavior is exactly as absurd as it sounds.

And BTW, "technically AV:L but feels like RCE" is your usual blog-post hype. It either is, or is not.

Right. I am surprised to see this considered to be an RCE. Or a "mad bug" worthy of being here on HN. sighs.

Pretty sure a lot of people have spent lots of tokens into finding RCEs in vim and emacs, he is not the first person to do this.

I would not mind remyelination + being on a DMT, heh.

That is 3D chess level type shit. xD

Yes timout indeed!

Jeez, that makes me feel old, and I am "only" just barely in 30. :(

Remember https://web.archive.org/web/20050204100149/http://cia.navi.c... BTW?

For the uninitiated: https://web.archive.org/web/20050129022102/http://cia.navi.c.... :D Good times!

This takes me back. It is just one of those artifacts of early 2000s that was associated with open source hacker culture. It truly felt magical at the time.

LOL I remember that stance. A good one!

I have never owned a GitHub account post-M$. :/ Mainly because I always knew Microsoft has always been against FOSS.

I have no skin in the game but that is a very charitable perspective.

And it should be "--" to begin with, i.e. "--hard".

I have done "Initial commit"s after having almost finished something. Sometimes fter >10k lines. Totally unrelated to LLMs, as I have done it years ago as well, and has nothing to do with LLMs. I see why you would think what you do though, but it does not logically follow.