saurik
saurik on Hacker News
Going about your job/life despite a looming threat is a different level of resignation than telling others not to worry and giving them a false sense of hope not because you truly understand the danger to be fake but because "what else am I to tell them? the truth is too horrible to bear" isn't actually doing anyone a kindness: it is going out of your way to make the jobs of those who would tell you the raw truth harder.
If you go to the doctor and they understand there there is a chance you are going to die but, when you come to them for advice on your pain, they look you straight in the eye and insist that you will be fine if you just eat some more fiber, they rob you and your family of a not only a chance to prepare and grieve but the motivation to fight the inevitable.
To your analogy, if you think we might be on the brink of a war that might massively effect your life and so you go to the wise guru who assures you you will be fine if you just duck and cover in the basement, they are, frankly, part of the problem, as they are making the war sound "not that bad", when if you understood the threat of thermonuclear war you might be protesting in the streets.
Just because the truth is inconvenient doesn't make it false.
I mean, right now, supposedly, we don't have enough energy to run as many AI data centers as everyone wants to build, and so big tech is getting into the power plant business to scale up: they'd love it if you stopped using energy they want to buy!
I don't see how being a hobby site makes it more sustainable to have crawlers making insane numbers of constant requests to your server for seemingly no good reason? If what used to be a website you could host for some small number of people who cared scaled well now it is a hundred times more expensive to run.
> I didn't find anyone claiming that two questions are duplicate of one another
in different programming languages unless the language is not relevant.
I am honestly at a loss here as to how you are not seeing this is a very different claim, and so am now also on the theory that this is some kind of performance art to reenact the frustration of someone claiming a question that is different is in fact some kind of duplicate content.
Again, this claim was made by a different user in a different branch of discussion off of this post, but it wasn't made by that user or even within this thread: Bratmon makes absolutely no claim about people crossing programming languages for marking duplicates. (I am done, though: feel free to now have the last word.)
(Not sure you'll see this, ofc.) After percolating on this for a couple days, is retrying the tool calls enough? Maybe the reason the tool call is requiring three retries is because the AI simply got locked into too difficult of a way to solve the problem, and if it retried the entire response it would have gone in a different direction entirely. How far back do we feel comfortable?
I would expect that, if you turned off the feature where they can use your data, that they would remove those features, so you don't either accidentally click them or fail to understand that it isn't some kind of local-to-your-account mechanism.
Right... and I said exactly that in both my comments, but I was looking for confirmation that that's the issue being stared at, as it wasn't obvious to me that's what was meant and (I will cite as demonstration of the confusion) now people are bringing up other ideas (such as field order, which is an entirely unrelated constraint). (FWIW, since you are the person I was originally asking, I will take this as positive confirmation that "yes: I am saying it is better to retry the entire tool call" ;P.)
I guess to be more concrete, I thought the way schema aware decoding worked should be identical to a token-level retry: "only even dice rolls are allowed" converting {0:0.1, 1:0.2, 2:0.2, 3:0.1, 4:0.2, 5:0.2} into {0:0.2, 2:0.4, 4:0.4}. That is why I am asking if the difference being stared at is doing the retry at the level of the entire tool call rather than each token (as this let's later errors in the schema re-roll the earlier committed states)? (But like, it isn't clear to me that's what they mean, so I feel a need to ask; as an example, you are now talking about field order, but that's an entirely different issue involving an overly-constrained constraint: nothing would prevent implementing the grammar for the constrained decoding to allow the fields in any order, and if you allow duplicate fields -- which JSON typically allows anyway -- then it is probably already supported as the language loses its additional context requirement.)
Is the schema constraint not implemented in a way where the new distribution is identically scaled to the old distribution with retry? I had thought the way it worked was just to disallow invalid next states... oh, or is the idea that you think it is much preferred to retry at the level of the entire tool call, rather than (conceptually) per token? I guess I can see that making a lot of sense, as maybe the model gets "backed into a corner", so to speak, with a really bad initial choice and is then trying to rescue horrible states?
Why do you believe that having an AI read my code and port it into your code base is "legal now"? Let's call that question A. This is a very different question from B whether it is legal to train a model on my code, which is also still a different question from C whether it is legal to use the model you trained on my code to generate code that is in any way similar to my code into your codebase.
As far as I know, A is still illegal, and nothing at all has changed that situation; if it did, it would be shocking, as it essentially undermines the entire legal framework of copyright, and it would be making national news and destroying -- not harming: entirely wiping out -- major software companies.
The only thing I think people have really litigated in the courts is B (as the obvious defendant is the juicy maker of the model rather than the users of the model, whereas they might be able to dodge culpability in C and even A), with the result that it is very likely legal... but, while that might be a bit frustrating, it was never shocking: a model is a highly transformative use case vs. the original code fed into the training.
However... B being legal doesn't actually imply that C is legal -- even if a ton of people fail to appreciate this distinction -- and C is where the war is starting to be fought. Instead of software, I think the most interesting avenue for this to become scary for people assuming this is legal will come from lawsuits involving the music industry (which tended to lead the pro-copyright cause in many of the skirmishes I was involved in while working on device freedom issues).
That said, people really focus too much on C, hoping for that grey area in both the law and in their analogies, when what developers are actually doing now is often A: the model has become an agent that uses tools, has access to the Internet, pulls code off my got repository, and is essentially just running a non-deterministic transform on that data sitting in its context... I have heard nothing that makes it sound as if A is "legal now".
1) I really wasn't talking about an editor at all: I was talking about the libraries and frameworks you use to program, so that the way you interact with the problem space is the way you think. I mean, even as someone who has almost exclusively used vim for the past 25 years of coding, if I went back to the prior 10 years before THAT of using Visual Studio, I'd have described this no differently.
2) In fact I have never used off-the-shelf coding assistants (Claude Code, etc.) and have only used my own harness; yet to me the issue is that the model itself often likes to think about problems in ways I find frustrating and unhelpful. The issue isn't at the level of how diffs are applied (that's commodity) or how context is managed (I can fix that) but in how problems are described, how abstractions are managed, and the language used to discuss them.
Yeah: in a world where I am coding, I can put in the effort to make the software work the way I think... to use an LLM, I largely have to think the way it wants to work / converse.
The entire concept of copyleft and free software depended on copyright: it isn't "take my code and do what you will", it is "here is a very explicit contract that demands you credit my work and even requires you to contribute back in return for my efforts". And like, maybe a world with no copyright at all is better! But that isn't the world we are in: it is no more legal for you to have an AI read my code and then port it into your codebase (which could involve training as an intermediate step or could merely involve the AI searching for it and loading it into its context) than would be for you to directly read my code and port it into your codebase or even for you to utilize a deterministic tool to read my code and port it into your codebase; you only get to do those things if you retain my license on the result and abide by its terms.
FWIW, many of us who do open source would also find that hypothetical world in which the idea of copyright is abolished rather enticing... but you pretending that is this current world whenever you want to steal our code whilst copyright still paints our interests in using and altering the code from companies that have always been in fear of our community and our licenses (Apple, Microsoft, etc.) as theft is not merely a bit shitty... it is kind of evil/cruel.
This position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
I think part of the problem -- answering all of why people are somehow OK with this, and even why the AI does this in the first place -- is that the majority of software developers never got to the point of understanding any of this: the lack of understanding how to carefully structure data surrounds a question they don't even know how to pose, much less answer, and so "write some tests then incrementally try to make them work without breaking any of the existing tests" is the only way they know how to develop at all. In the end, that means that, with the current state of the art (which might change, of course... potentially quickly), your strategy of treating the AI as a junior engineer who fundamentally isn't ready to do your senior-level architecture job makes a lot of sense.
Reducing access to a weapon/tool behind any variety of roadblocks because you think the weapon/tool is dangerous is not the same as shifting blame off of the person who did the crime. Saying we don't want people to be able to buy guns without limitations or even saying people should not be allowed to make or sell certain kinds of weapons/tools is not the same thing as saying the person who jumped through the hoops (or ducked underneath them) is not liable for the crime they committed using the weapon/tool. It is certainly the case that no one, at the end of the day, claims the gun is to blame for the murder a human carries out with it... some people will claim maybe the humans making or selling the gun share some blame, but it would be a fundamental attribution error to blame the gun itself.
BTW, as kind of a follow-up to this, I think the most important finding to report--for those who only use one model, as many people seem to--is just how much more often Claude seems to be extremely confidently (and even insufferably) wrong than any of the other three big models (all of which I use quite often... yet I only pull out Claude when I've given up hope in a problem and are looking for out-of-the-box brainstorming).
And like, it does this despite it speaking in extremely dense math, which both makes it sound correct and requires a lot more effort to prove when it is wrong... yet, it isn't actually correct more often, and so that time sink just isn't worth the benefit. I then think many people--including people who can speak math (as can I)--just stop bothering to check everything, as if you come across a human who speaks like this it probably does correlate with slow and careful thought that helps prevent errors.
Instead, Claude has the mistake rate of a somewhat accelerated beginner impossibly combined with the language of an expert professor; and we as humans just aren't good at that combination: it becomes very dangerous and makes it take longer to spot its egregious mistakes and trained-in biases. If you have to use Claude, I thereby claim you really need to have a team of not-Claudes to help insulate you from this, and Gemini (while being a bit senile) is a lot more collaborative and approaches problems in ways that makes it harder to get tricked.
(To translate this into more of an engineering analogy: Claude always feels to me like the engineer who put more effort into learning how to program in functional languages than into how to actually develop working code, and then confidently presents you answers in Haskell or Lisp that never quite work. To find their errors is then very costly. In contrast, Gemini feels more like a Java or Go developer who knows they are a cog... that's helpful! <- Which maybe just goes to show that AI has finally turned me into a manager, omg.)
Not in the principled sense you mean but I have in fact recently started having Gemini explain to me what Claude is talking to me about, lol.
Doesn't it feel like the exact opposite? If you care a lot about the AI being a vengeful god, you do not do what OpenAI and Anthropic are doing. These companies only pay lip service to the idea of that aspect of AI safety in the hope that they can use it to regulate open source AI out of existence.
Instead, they are focused on stuff like "can I ask the AI to help me build a nuclear bomb" or "is the AI willing to generate pornographic stories", which is neither trying to protect us from unleashing a vengeful god NOR preventing (in any honest way) the today-level problems you (very correctly) bring up.
This same level of "oops" in the backend causes users to accidentally see or delete other user's photos, which is definitely a categorically worse scenario.
No that command is "adb install". The "adb sideload" command (which I did not even realize existed) is for installing custom firmware.
If you merely deactivate your email address rather than closing your account or changing your notification settings or whatever, then the next time a legitimate service goes to send you a legitimate email that you asked for, it will bounce. In some sense this "shouldn't matter", as in a purely P2P system the only people who would notice are the sender and Apple -- and Apple knows what is going on, so should not penalize senders the way, say, Google would if they see you sending a ton of email to their domains and they all bounce -- but people tend to use services to help send email and centrally pool their reputation (such as mailchimp) and so these services themselves then watch the bounce rate of their individual customers and either charge them more or ban their access due to the bounce rate increase.
And yet why are people going out of their way to send multipart emails with useless parts? Your analogy does not fit as the Amish person is potentially refusing the HTML part: I just cited my preference, confirming to the protocol, and am being actively sent garbage information as somehow someone seriously thought it was easier for them to go out of their way to give me the option and then laugh at me for making the wrong choice than to just send an email that is HTML only.
Darling stopped using the kernel module a year ago.
But the whole point was that it wasn't a separate role: it was a re-distribution of work so the developers were doing operations. Instead, a lot of people entirely missed the point and just renamed their ops people to devops.
I honestly feel like it is the point at which you find field arithmetic intuitive that demonstrates you have finally understood computers.
Life is longer than a lot of people seem to think. I put a lot of effort into configuring vim and bash... 20 years ago maybe? And now I barely think about it, but the changes I made have made me more efficient and effective throughout those 20 years. Go ahead and put some time into figuring out how you use a tool and make scripts or aliases for using them... if you invest in good tools you will get decades of use out of, instead of chasing dumb fads, you'll just keep compounding your efficiency.
I am unsure, then, as to what your actual goal is? Like, what would you have someone come away from your comment having learned? The comment did not even say the tech IS a doomsday device, it was trying to remove the actual description entirely--so it didn't matter if it was AI or nuclear energy or what--and the
placeholder was "doomsday device", as that's what a person who only hears the rest of the sentence is ever going to take away from it.
I do, in fact, think that, if someone says "my technology -- call it what you will, and I won't bother to tell you what it is -- is so dangerous that in the wrong hands or if it isn't carefully contained in a way that I am going to great lengths to try to accomplish it can end the world" -- which is what these people at these companies are saying -- that it would be hard-pressed to not be willing to call that a "doomsday device". I would even go so far as to claim that the exact opposite is more likely true: that to not want to do so requires you to have some extremely awkward bias yourself.
Sure: me using that label to ascribe something related to this product makes some people, seemingly you included, feel bad, and so maybe we can say it involves a "bias", as I clearly can avoid that label, but chose not to, and in so doing colored the discussion in a way that makes you unhappy... but it doesn't make it untrue anymore than any other purely descriptive term is now-a-days often said to be biased. As they like to point out: "reality has a liberal bias" (even if it is just as often liberals annoyed with the terms being used by people ;P).
Again: the bias against the use of that term seems much more fascinating than being upset at the idea that the parable -- which of course is trying to make a point, and so is inherently biased towards that point -- could be attempting to temporary apply it, particularly so as it seems to lead to blindness to what actually happened: people will hear you saying your tech is dangerous, and it will be banned and regulated.
And that's related to why I maintain that I think your example disproves your own attempt at a point: you try to draw a parallel to another technology, as if once we find out it is nuclear reaction research we of course know that that isn't a doomsday device... and yet that is one of the few things that is most obviously to the most people a doomsday device, it is a thing that even the people working on it have always felt might not just be a doomsday device but might be "the" doomsday device (as in, the one that actually does us in), and there has not only been countless people out there worried about what can and will happen in its usage, but it was in fact weaponized and a very very large number of people died due to it, so to try to make the argument that it would be biased to call it a "doomsday device" itself feels very awkward.
But, sure: we can decide that that's biased and throw out the "dunno it sounds like a doomsday device and should be regulated" argument as the argument itself has a bias in it, and that leaves us with... what? A world in which people make these things, talk about how dangerous they are, and then feign in shock and frantically try to backpedal when governments step in to prevent it from being released without careful analysis and regulation and study and planning?