Yeah it's a huge mistake IMO. I see it fucking up titles so frequently, and it flies in the face of the "do not editorialise titles" rule:
[...] please use the original title, unless it is misleading or linkbait; don't editorialize.
It is much worse, I think, to regularly drastically change the meaning of a title automatically until a moderator happens to notice to change it back, than to allow the occasional somewhat exaggerated original post title.
As it stands, the HN title suggests that Raymond thinks the C++ 'try' keyword is a poor imitation of some other language's 'try'. In reality, the post is about a way to mimic Java's 'finally' in C++, which the original title clearly (if humorously) encapsulates. Raymond's words have been misrepresented here for over 4 hours at this point. I do not understand how this is an acceptable trade-off.
Submissions with titles that undergo this treatment should get a separate screen where both titles are proposed, and the ultimate choice belongs to the submitter.
Personally, I would rather we have a lower bar for killing submissions quickly with maybe five or ten flags and less automated editorializing of titles.
While I disagree with you that it's "a huge mistake" (I think it works fine in 95% of cases), it strikes me that this sort of semantic textual substitution is a perfect task for an LLM. Why not just ask a cheap LLM to de-sensationalize any post which hits more than 50 points or so?
A better approach would be to not so aggressively modify headlines.
Relying on somebody to detect the error, email the mods (significant friction), and then hope the mods act (after discussion has already been skewed) is not really a great solution.
It has been up with the incorrect title for over 7 hours now. That's most of the Hacker News front-page lifecycle. The system for correcting bad automatic editorialisation clearly isn't working well enough.
Oh, come on man! These are trivial bugs. Whoever noticed it first should have sent the email to the mods. I did it before i posted my previous comment and i now see that the title has been changed appropriately.
Presumably nobody informed the mods (before i did) and it was very early in the morning in the US (assuming mods are based in the US). That would explain the delay.
Anyway, going forward, if anything like this happens again folks should simply shoot an email immediately to the mods and if the topic is really interesting deserving of more discussion they can always request the mods to keep the post on the frontpage for a longer time period via second-chance pool etc.
It just takes a minute or two of one's time and hence not worth getting het up over.
It would be easier for everyone involved, and not depend on mods being awake, if HN didn't just automatically drastically change the meaning of headlines.
Again, this post was misrepresenting Raymond's words for over 7 hours. That's most of its time on the front page. The current system doesn't work.
This is the first time i have seen the auto-editorializing algorithm make a mess of the semantic meaning of a sentence which is certainly unfortunate. In most other cases (which are quite rare btw) it is generally much more benign. I presume the mods will be taking another look at their algorithm.
However, given the ways people try to influence the content on HN via title, language, brigading etc. it is good that the algorithm be strict rather than loose to prevent casual gaming of the system. And it works quite well contrary to your claim.
It's rare to see the mangling heuristics improve a title these days. There was a specific type of clickbait title that was overused at the time, so a rule was created. And now that the original problem has passed, we're stuck with it.
I intentionally shortened the title because there is a length limit. Perhaps I didn't do it the right way because I was unfamiliar with the mentioned meme. Sorry about that.
Given what this person has gone through, if you want to be critical then I think you owe us a more detailed explanation what exactly would have worked better. Armchair parenting is very easy.
Out of all bugs and feature requests, this one is an outlier in that it requires specific hardware to work on and has an obvious success condition. This means that every man and his dog is not going to be throwing an LLM at this to see if their particular slop wins the prize. People get weird when money is on the line and managing a bounty is a job for which I would never volunteer.
MetaARPA tier membership (quarterly fee) is required to have HTTPS on your personal website - personal sites hosted on the main BSD cluster don’t have it.
One place bisect shines is when a flaky test snuck in due to some race condition but you can’t figure out what. If you have to run a test 100000 times to be convinced the bug isn’t present, this can be pretty slow. Bisecting makes it practical to narrow in on the faulty commit, and with the right script you can just leave it running in the background for an hour.
Spam, illegal content, and moderation in general. How do you protect against new account spam when any domain could be a PDS and any PDS could host an arbitrary number of users? What do you do about people stuffing ebooks and TV shows in git repositories? If a project is getting piled on with all its issued spammed because of political views of the repo's maintainer, is this considered a problem, and if so how is it fixed?
The advantage of an AppView is that, like BlueSky, you can actually have a central moderation team and consistent moderation policy. Even if people post whatever they want on their own PDS it is possible to curate what people normally see. However, even though I avoid following the drama I can see that the BlueSky moderation team is constantly under fire for some decision or other. Choose your poison.
Nowadays I don't have the appetite for fully decentralised public networks and all the responsibilities and problems they bring. It's nice that AT's content is completely open compared with something like Twitter, but it's so helpful that the day-to-day administration is centralised when you want an authority to appeal to without ending up with the quagmire of "defederation".
A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node? (i.e. providing storage and access to arbitrary git repos uploaded anonymously)
But doesn't the decentralized firehose make it easy to build curation? You decide what/whom you want to subscribe to---rest of social media be damned. Why do you care what unmoderated crap is flooding the world outside your cosy corner?
And if you choose to receive a broader sampling, you can subscribe to someone who will curate it for you---either manually, or through algorithms. It seems like an elegant way to have a web-of-trust layer for curation, composed with an algorithmic curation layer---and be able to tune the latter separately to suit user needs, without being beholden to the interests of the platform operator. You can easily switch your subscriptions if you don't like the way someone is curating it, without wholesale losing access to the network!
> A question to ponder: is anyone here going to volunteer to run a "permissive" radicle seed node?
Doesn't opening up curation+subscription solve this problem too? Anyone can curate in opinionated ways, and offer to "host" whatever they are okay with accepting responsibility for (at whatever level of endorsement, so long as it is clearly communicated) and users have the choice to subscribe.
The problem today is that curation is tangled with access to the network, so you're forced to accept the curation provided to you by the owner of the walled garden (and incentives are misaligned)
AtProto does have platform and user managed labelers for the moderation piece, so it's at least built into the protocol. The jury is still out on how well that concept will scale.
I think if somebody wants to see library distribution channels tightened up they need to be very specific about what they would like to see changed and why it would be better, since it would appear that the status quo is serving what people actually want - being able to create and upload packages and update them when you want.
> But right now there are still no signed dependencies and nothing stopping people using AI agents, or just plain old scripts, from creating thousands of junk or namesquatting repositories.
This is as close as we get in this particular piece. So what's the alternative here exactly - do we want uploaders to sign up with Microsoft accounts? Some sort of developer vetting process? A curated lib store? I'm sure everybody will be thrilled if Microsoft does that to the JS ecosystem. (/s) I'm not seeing a great deal of difference between having someone's NPM creds and having someone's signing key. Let's make things better but let's also be precise, please.
> But right now there are still no signed dependencies
Considering these attacks are stealing API tokens by running code on developer's machines; I don't see how signing helps, attackers will just steal the private keys and sign their malware with those.
postinstall is running on the developer's machine, from an endpoint security perspective, it's the actual developer performing the malicious actions, their machine, their IP address and their location.
Crates.io had a major phishing campaign just the other day, but no major hacks yet as far as I know. Is that because they do something special that NPM has failed to do? Or is it just that NPM is a big and juicy target?
We treat code repositories as public infrastructure, but we don't want to pay for it, so corporations run them, with their profit interest in mind. This is the fundamental conflict, that I see.
And one solution, more non profits as organisations behind them.
In addition to what's already in the thread, I assume by now somebody has vibecoded an agent to scan GitHub for bounties and then automatically vibe up a corresponding solution. Will be a fun source of spam for anyone who wants to do the right thing and pay people for good work.
I recently got my first AI generated PR for a project I maintain and it was honestly a little stressful.
My first clue was that PR description was absurdly detailed and well structured... yet the actual changes were really scattershot. A human with the experience and attention to detail to produce that detailed description would likely also have broken it down into seperate PRs.
And the code seemed alright until I noticed a small one-line change: a UI component had been replaced with a comment that stated "Insantiating component now requires X"
Except the new insantiation wasn't anywhere. Their coding agent had commented out insantiating the component instead of figuring out dependency injection.
That component was the container for all of the app's settings.
-
It's interesting because the PR wasn't entirely useless: individual parts of it were good enough that even if I took over the PR I'd be fine keeping them.
But whatever coded it couldn't understand architecture well enough. I suspect whoever was piloting it probably tested the core functionality and assumed their small UI changes wouldn't break anything.
I hope we normalize just admitting when most of a piece of code is AI generated. I'm not a luddite about these tools, but it also changes how I'll approach a piece of code.
Things that are easy for humans get very hard for AI, and vice versa.
> I hope we normalize just admitting when most of a piece of code is AI generated.
People using AI tools in their work is becoming normal. In the end, it doesn't matter how the code is created if the code works and is otherwise high quality. The person contributing is responsible for checking the quality of their contributions. Generally, a pull request that changes half the system for no good reason without good motivation is clearly not acceptable in most OSS systems. Likewise, a pull request that ignores existing design and conventions is also not acceptable. If you do such a pull request manually, it will probably also get rejected and get told off by repository maintainers.
The beauty of the pull request system is that it puts the responsibility on the PR creator to make sure their pull request is good enough. Creating huge pull requests is generally not appreciated and creates a lot of review overhead. It's also good practice to work via the issue tracker and discuss your plans before you start the work. Especially with bigger changes. The problem here is not necessary AI but but people using AI to create low quality pull requests and people not communicating properly.
I've not yet received any obvious AI generated pull requests on any of my projects. But I've used codex on my own projects for a few pull requests. I'd probably disclose that fact if I was going to contribute something to somebody else's code base and would also take the time to properly clean up the pull request and make sure it delivers as promised.
Not only admitting, it should be law to mark anything AI generated as AI generated. Even if AI contributed just a tiny bit. I dont want to use AI slop, and I should be allowed to make informed decisions based on that preference.
Ah yes the duality of anti-AI crowds on HN. “GenAI is just fancy autocorrect”, and “autocorrect isn’t actually GenAI”.
The thing is, if you’re talking about making laws (as GP is), your “surely people understand this difference” strategy doesn’t matter squat and the impact will be larger than you think.
You don't seem to understand what people mean when they say "AI is just fancy autocorrect". People talk about the little word suggestions over the keyboard, not about correcting spelling. And yes, of course those suggestions are going to be provided by some sort of ML model, and yes if you actually write a whole article just using them, it should be marked as AI generated, but literally no one is doing that. Maybe because it's not fancy enough autocorrect. Either way, this is not the gotcha you think.
A law like this would obviously need some sort of sensible definition of what "AI" means in this context. Online translation tools also use ML models and even systems to unlock your device with your face do, so classifying all of that as "AI contributions" would make the definition completely useless.
I assume the OP was talking about things like LLMs and diffusion models which one could definitely single out for regulatory purposes. At the end of the day I don't think it would ever be realistically possible to have a law like this anyway, at least not one that wouldn't come with a bunch of ambiguity that would need to be resolved in court.
OK, so define it for us, please. Because, once again, this thread is talking about introducing laws about "AI". OP was talking about LLMs you say - So SLMs then are fine? If not, then where is the boundary? If they're fine then congratulations you have created a new industry of people pushing the boundaries of what SLMs can do, as well as how they are defined.
Laws are built on definitions and this hand-wavy BS is how we got nonsense like the current version of the AI act.
Why are you so mad at me, I'm not even the OP you should ask these questions. I'm also not convinced we need regulation like this in the first place, so I can't tell you where this boundary should be, but a boundary could certainly be found and it would be beyond simple spellchecking autocorrect.
I also don't understand why you think this would be so impossible to define. There are regulations for all kinds of areas where specific things are targeted like chemicals or drugs and just because some of these have incentivized people to slightly change a regulated thing into an unregulated thing does not mean we don't regulate these areas at all. So how are AI systems so different that you think it'd be impossible to find an adequate definition?
It’s already there for Apple developers: https://developer.apple.com/documentation/foundationmodels
I saw some presentations about it last year. It’s extremely easy to use.
reply