Live data from Hacker News

Linux security mailing list 'almost unmanageable'

theregister.com

41–50 of 116 posts

Re: Linux security mailing list 'almost unmanageable'

#41
So ... first, AI slop is killing mankind slowly. Skynet is winning here.

On the other hand ... IF the bug report is real, and let's assume that AI slop reports at the least a few bugs that are indeed real, then I really think it should not make a difference WHO or WHAT reports these bugs. I would not disagree on fake bugs or bogus bug reports wasting time of humans, but this is a quality difference then. Surely people can tweak AI models to be better at finding bugs too. Besides, they should auto-fix that. Is AI still too stupid to fully replace humans? Other than killing them with spam, as it does right now.

Re: Linux security mailing list 'almost unmanageable'

#42
post #9

Fun fact (or not so fun if you're a subscriber): Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now. https://lore.kernel.org/all/CAGg4U=GNtCObd_Nbm_1Rr5FEvPb69Yz...

I'd warn HN users not to click on that link simply because it will load a 26Mb message that will likely cause quite a strain on kernel.org's servers if everyone here does it.

Thank you for the warning. I rarely click on links these days though; only exception I make for HN links for main articles.

Re: Linux security mailing list 'almost unmanageable'

#43

Earlier quoted context omitted.

I'd warn HN users not to click on that link simply because it will load a 26Mb message that will likely cause quite a strain on kernel.org's servers if everyone here does it.

Does a 26MB message actually cause noticeable strain on the server much beyond loading the page? I would think serving a contiguous 26MB chunk would be relatively similar to say 20 normal sized messages.

[deleted]

Re: Linux security mailing list 'almost unmanageable'

#44
post #31

I think it's time the report-only intake should stop. If a reporter can't reproduce at least one use case or can't summarise it in two sentences, it should be classified as spam. LLMs write beautiful reports, it's just that sometimes it doesn't bear anything resembling the truth.

couldn't an llm be used for verification like we're seeing some OSS projects do? Some projects are moving so fast, its almost certain there's little human involvement.

Re: Linux security mailing list 'almost unmanageable'

#47
post #36

It seems like LLMs are actually pretty good at the sorts of things needed to manage a high-volume mailing list (summarizing, looking for dupes, sentiment, flagging things, etc), even if only as augmentation for human eyes. That said, I get why this would rankle a lot of the folks involved.

That's just a security/protection racket with extra steps: "Someone is paying us to hurt your business/site; pay us money to defend your site against our attacks".

Re: Linux security mailing list 'almost unmanageable'

#48
post #9

Fun fact (or not so fun if you're a subscriber): Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now. https://lore.kernel.org/all/CAGg4U=GNtCObd_Nbm_1Rr5FEvPb69Yz...

I'd warn HN users not to click on that link simply because it will load a 26Mb message that will likely cause quite a strain on kernel.org's servers if everyone here does it.

I was curious how much of an impact HN could have. Napkin math:

HN gets 24M views a day. Assume those views are evenly distributed across the front page (they aren’t), and that’s about 1M views for each front page post, assuming each user clicks on one post.

By the rule of 10s (also not exact), there are 10x less views on comment threads. So assume around 100k views on a comment thread as a theoretical average.

If everyone in this thread clicked on the link, that would be 2.6 TB of transfer across the day. But by the rule of 10’s we have to assume 10x fewer people will interact (upvote, click, anything) than view. So we’re down to 260GB transfer over the course of a day.

I wonder how close that is. It seems plausible that a link in the top comment of a thread could garner 10,000 clicks.

That’s still about one click every 8 seconds, which at 10Mbit/s would indeed overwhelm the server by a factor of about 2.5x. But I clicked through and it loaded in just a few seconds, so presumably the pipe is faster than 10Mbit/s.

Another caveat is that many websites are already several megabytes, so it seems strange that 26Mb would be the breaking point for a reasonable web host.

Re: Linux security mailing list 'almost unmanageable'

#49

Will never understand why some people prefer mailing lists to do development, it always feels like the most convoluted way to hold a discussion, especially if there are multiple topics at the same time. It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else.

A good mailclient allows a skilled user a much more efficient communication than most forums. > It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else. True, external moderation is a benefit of centralized platforms, but a mailclient allows personalized moderation, which all…

Is there a demo of such communication on YouTube, or at least some article with screenshots?

Re: Linux security mailing list 'almost unmanageable'

#50

Earlier quoted context omitted.

https://web.archive.org/web/20260518134447/https://lore.kern...

I don't think needlessly straining the Internet Archive's servers is any better.

IA's infra is slightly better for big loads though, they tend to just have higher latency rather than aborted/timed out requests, for better or worse. It can be bit slow, but as long as you're ready to wait, you'll eventually get the response. Usually hosts just cut you off with a hardcoded timeout instead, which for people on high latency/low bandwidth connections can be super fun.
Post reply on HN