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

131–140 of 164 posts

Re: Significant raise of reports

#131

Post by SoftTalker »

radlad wrote: post #116
mentalgear wrote: post #105

Earlier quoted context omitted.

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.

Embedded code is also simpler because it has to be. When you are confined to a microcontroller, there isn't room for bloated app frameworks, hundreds of NPM packages, etc.

Re: Significant raise of reports

#132

Post by par1970 »

tptacek wrote: post #123
par1970 wrote: post #118

Earlier quoted context omitted.

> 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.

I don't think that's it; both reading the code and running tests are a posteriori capabilities.

Yeah, maybe you are right. But is doing math and reasoning about Turing machines a priori? If so, then it seems plausible to me that reasoning about a codebase (without running it) is also ‘a priori’.

Re: Significant raise of reports

#133

Post by marcosdumay »

charcircuit wrote: post #127
marcosdumay wrote: post #108

Earlier quoted context omitted.

If your program's auto-save works like that, it's broken. Almost none do, though. Auto-save almost always writes to a temporary file, that is erased when you save manually.

Google Docs and VS Code are the first two that come to mind for autosave and they don't use a temp file.

Yeah, source code editors tend to do that. They integrate with external tools that expect to read those files, so if they don't overwrite them, those tools would run the wrong version. It would still be better if they didn't.

Text editors shouldn't do that though. And those shared-view editors that don't have the concept of saving have this very relevant drawback.

Re: Significant raise of reports

#134

Post by motbus3 »

The slapocalipse is here, but I would propose the idea that open source maintainer get free access to AI tools from these big companies, so at least they can aggregate the problems and have some level of automation of the process.

For me, this seems something that would make sense for all dev community to push for.

Re: Significant raise of reports

#135

Post by sigbottle »

tptacek wrote: post #123
par1970 wrote: post #118

Earlier quoted context omitted.

> 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.

I don't think that's it; both reading the code and running tests are a posteriori capabilities.

No you're right. I initially thought you were wrong but it is sus.

My intuition for a priori cut something along the lines of, "Even if you had the entire source code in your head at once, there's limits to reasoning about it". Computability is one hard result. You also have to interact with the real world on a wide variety of hardware systems, or even just a wide variety of systems if you create an API - how do you reason past the abstraction boundary reliably without actually having tests and interacting with systems and getting feedback? Not really possible unless LLM's control everything. More philosophical questions (such as "is our 'correct' actually the right thing?") we grant the easy case that everybody's in consensus - the "easier" problems show up either way.

But getting to the point of "understanding in principle every piece of linux" is pretty undefined and practically doesn't seem possible for a singular LLM or a human. This also seems really hairy for smuggling in whatever implicit premises you want to swing the issue either way.

But personally I (and many other people) have seen late 2025 models get extremely good, and that precisely is because they actually started doing deep tooling and like, actually running and testing their code. I was not getting nearly as much value out of them (still a decent amount of value!) prior to the tooling explosion, not even MCPs were good. It was when they actually started aggressively spawning subshells and executing live tests. But I guess using a priori/posterioi isn't really a useful split here?

Re: Significant raise of reports

#136

Post by 0x3f »

bastawhiz wrote: post #46
cafebabbe wrote: post #41

Earlier quoted context omitted.

Not by everyone, so that would be better than nothing.

Excited to have to do SEM for my GitHub profile so that people will read my pull requests

Well it's all going to be social credit one day. Might as well get in practice early.

Re: Significant raise of reports

#137

Post by taeric »

LatencyKills wrote: post #110
miki123211 wrote: post #93

Earlier quoted context omitted.

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).

I used to joke that using something like Python or C# felt like "programming with oven mitts". I never felt like I had any control. But that eventually morphed into "Well, I don't need that control and can focus on other things." I spent the last few months building a toy LLM from scratch. I can't believe that within my lifetime I've gone from using punch cards to arguing with Claude when it does something ridiculous…

The oven mitts metaphor probably works really well, if you shift it into metal working. Yes, it takes getting used to wearing heavy gloves when working. No, you don't want to skip out on them.

Edit: Honestly, any job where gloves are standard works. Gardening. Sailing. Many sports.

Re: Significant raise of reports

#138

Post by IshKebab »

tptacek wrote: post #91
IshKebab wrote: post #74

Earlier quoted context omitted.

Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.

Everything has a poor security track record. That's the point.

1. That's bollocks. Obvious bullshit. All software doesn't have the same security track record. Do you also think sendmail and seL4 have an equally poor security track record?

2. Even if everything did have an equally poor security track record, why would that mean security bugs are no more significant than any other bug?

Honestly I'm dubious you've thought about this at all.

Re: Significant raise of reports

#139

Post by socalgal2 »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

> Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug.

The point is that all of those bugs are now trivial to exploit and so will be exploited

Re: Significant raise of reports

#140

Post by akerl_ »

cperciva wrote: post #121
akerl_ wrote: post #96

Earlier quoted context omitted.

Well, except OpenBSD. They’ve only had two vulns in forever.

Only two remote code execution vulnerabilities in the default configuration. But that's not the only type of security bug.

As `tptacek caught on to, I was joking since OpenBSD's published claim is such a convenient comparison to the idea upthread that Linux specifically had a poor track record.
Post reply on HN