Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

111–120 of 164 posts

Re: Significant raise of reports

#111

Post by layer8 »

miki123211 wrote: post #93
LatencyKills wrote: post #69

Earlier quoted context omitted.

I wouldn't take that as criticism; you are 100% correct. But that instability was a direct result of the issues I mentioned above: the ring transition protection/implementation was absolutely horrible; 3rd-party developers would discover a useful function in NTDLL and start using it in unintended ways, etc. Do you remember the CSRSS Backspace Bug? [0] A simple: printf("hung up\t\t\b\b\b\b\b\b"); from ring-3 would res…

I can't imagine how much of a breath of fresh air Python / Java must have been if you were used to write typical business crud apps (and server software) in C/C++ (with no sanitizers / modern tooling to speak of).

It wasn’t. Java was very different from its current state before roughly Java 5. It felt like a downgrade from C++ to me at the time. C++ had templates and RAII and smart pointers, all of which Java lacked (and in some respects still lacks today). Not having something like the C preprocessor was quite annoying. Java performance wasn’t great. Tooling was better in some ways, worse in others. Linters did exist in C/C++, as did debug versions of libraries. You could load a crash dump into a debugger and could often get a pretty good picture of what went wrong. While Java certainly became preferable for business code, it wasn’t a sudden breath of fresh air, it was trade-offs that gradually became more favorable to it over the years.

Re: Significant raise of reports

#112

Post by parliament32 »

tptacek wrote: post #98
_se wrote: post #80

Earlier quoted context omitted.

It can be correct and slop at the same time. The reporter could have reported it in a way that makes it clear a human reviewed and cared about the report. Slop is a function of how the information is presented and how the tools are used. People don't care if you use LLMs if they don't tell you can use them, they care when you send them a bunch of bullshit with 5% of value buried inside it. If you're reading something…

No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report. This is in the linked story: they're seeing increased numbers of duplicate findings , meaning, whatever valid b…

> There's no such thing as a "slop vulnerability"

https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...

See the list at the bottom of the post for examples.

Re: Significant raise of reports

#113

Post by sigbottle »

I'm actually curious about AI progress:

There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently.

Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powerful.

That's cool! I've always wanted to learn how kernel devs properly test stuff reliably but it seemed hard. As someone who's dabbled in kernel dev for his job. Like real variable hardware, and not just manual testing shit.

Honestly, AI has only helped me become a better SWE because no one else has the time or patience to teach me.

Re: Significant raise of reports

#114

Post by tptacek »

parliament32 wrote: post #112
tptacek wrote: post #98

Earlier quoted context omitted.

No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report. This is in the linked story: they're seeing increased numbers of duplicate findings , meaning, whatever valid b…

> There's no such thing as a "slop vulnerability" https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s... See the list at the bottom of the post for examples.

Those aren't vulnerabilities. You're missing the point.

Nobody is saying there's no such thing as a slop report. Not only are there, but slop vulnerability reports as a time-consuming annoying phenomenon predate LLM chatbots by almost a decade. There's a whole cottage industry that deals with them.

Or did. Obsolete now.

Re: Significant raise of reports

#115

Post by tptacek »

sigbottle wrote: post #113

I'm actually curious about AI progress: There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently. Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powe…

What do you mean "a priori understanding codebases"? Quantify it and let's test specifically what you mean. Linux is huge.

Re: Significant raise of reports

#116

Post by radlad »

mentalgear wrote: post #105
psychoslave wrote: post #73

>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target. Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed elec…

There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option". Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "…

Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code."

Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.

Re: Significant raise of reports

#117

Post by tosti »

tolciho wrote: post #54
dspillett wrote: post #15

Earlier quoted context omitted.

Also in terms of security, there was generally a much smaller potential attack surface and those surfaces were harder to reach because we were much less constantly connected.

Except that when you did connect Windows to anything it was hacked in less than 30 seconds (the user ignored the "apply these updates first, and then connect ..." advice, they wanted some keyboard driver. Hacked, whoops, gotta waste time doing a wipe and reinstall. This was back when many places had no firewalls). IRIX would fall over and die if you pointed a somewhat aggressive nmap at it, some buggy daemon listenin…

Not just dhcpd. Besides the entire existance of Wine and Samba, Qemu has a workaround for win2k. Mkudffs has a workaround for MS-Windows not being able to read the filesystem without an mbr. Libc can work with local system time for those who dual-boot. Git can work around the difference in line endings. There are probably more of these kludges than you can shake a stick at.

Re: Significant raise of reports

#118

Post by par1970 »

tptacek wrote: post #115
sigbottle wrote: post #113

I'm actually curious about AI progress: There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently. Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powe…

What do you mean "a priori understanding codebases"? Quantify it and let's test specifically what you mean. Linux is huge.

> What do you mean "a priori understanding codebases"?

I took him to be distinguishing between (1) just reading the code/docs and reasoning about it, and (2) that + crafting and running tests.

Re: Significant raise of reports

#119

Post by _se »

tptacek wrote: post #98
_se wrote: post #80

Earlier quoted context omitted.

It can be correct and slop at the same time. The reporter could have reported it in a way that makes it clear a human reviewed and cared about the report. Slop is a function of how the information is presented and how the tools are used. People don't care if you use LLMs if they don't tell you can use them, they care when you send them a bunch of bullshit with 5% of value buried inside it. If you're reading something…

No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report. This is in the linked story: they're seeing increased numbers of duplicate findings , meaning, whatever valid b…

Everyone is free to be as snooty as they like. If a report is harder to read/understand/validate because the author just yolo'ed it with an LLM, that's on the report author, not on the maintainers.

It's not okay to foist work onto other people because you don't think LLM slop is a problem. It is absolutely a problem, and no amount of apologizing and pontificating is going to change that.

Grow up and own your work. Stop making excuses for other people. Help make the world better, not worse. It's obvious that LLMs can be useful for this purpose, so people should use them well and make the reports useful. Period.

Re: Significant raise of reports

#120

Post by tart-lemonade »

glimshe wrote: post #4

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…

It feels like rose-tinted glasses. While lots of low-hanging fruit had to be plucked to be shippable, there was still plenty of software which mandated specific hardware/software combinations or (worse) had major bugs which weren't patched but had workarounds documented in the manual, and if you weren't actively reading the manual, your newly-purchased software just wouldn't work (and if it was something low-level, that may mean you have to reinstall the OS).

Then there was stuff like rwall, which could be used to scrawl a message across basically every terminal connected to a networked Unix box in the world by accident [0][1], and it was far from the only insecure-by-design Unix software in widespread use.

It's interesting to watch youtubers like clabretro [2], NCommander [3], and Old Computers Sucked [4] who have documented the slog that was setting up and patching networking equipment, obscure Microsoft products, Netware, Unixes and Unix hardware, old Linux distros, etc. We take so much for granted these days. We don't even have to think about C/++ standards compliance outside the occasional compiler bug, much less the myriad of mutually-incompatible POSIX implementations that helped Microsoft win the Unix wars.

The fact that you can just build a PC with no prior experience or IT knowledge after watching an hour-long youtube video rather than having to spend weeks researching hardware compatibility or futzing about with IRQ levels, recompiling kernels, and messing with autoexec.bat/config.sys is a testament to how far we have come. You don't even have to think about drivers anymore unless you have specialized equipment.

[0]: https://news.ycombinator.com/item?id=31822138

[1]: https://news.ycombinator.com/item?id=35759965

[2]: https://www.youtube.com/@clabretro

[3]: https://www.youtube.com/@NCommander

[4]: https://www.youtube.com/@old-computers-sucked

Post reply on HN