Earlier quoted context omitted.
What do you use that low spec machine for?
It is a backup machine for important files. Plus testing items I develop to see how they run in limited environments.
NetBSD 9.5 released and EOL for NetBSD-9
11–20 of 20 posts
Re: NetBSD 9.5 released and EOL for NetBSD-9
#12Earlier quoted context omitted.
Totally inaccurate comparison. Garbage dumped on the side of the road is still garbage. It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds. Someone would be happy to take them and none the wiser.
> It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds. Equating LLM generated code to "lab-grown diamonds" is disingenuous at best. > Someone would be happy to take them and [be] none the wiser. If the quality of GenAI PRs were equivalent to those authored by experienced contributors, then there would not be as many GenAI PR bans in FOSS…
If it "looks like claude" in that it's overly verbose (in code or comments), missing tests, etc then it should be rejected for lack of merits. If the only indication is "this user fixed 10 bugs in an hour" and the PRs are otherwise fine on the merits, rejecting the PRs because an LLM wrote them is the same as rejecting them because you know they're from an emacs user.
Re: NetBSD 9.5 released and EOL for NetBSD-9
#13Earlier quoted context omitted.
> It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds. Equating LLM generated code to "lab-grown diamonds" is disingenuous at best. > Someone would be happy to take them and [be] none the wiser. If the quality of GenAI PRs were equivalent to those authored by experienced contributors, then there would not be as many GenAI PR bans in FOSS…
The quality of GenAI PRs scales with the driver. Many are low-effort, ill-considered, overly verbose and otherwise bad. I've seen decades of similar patches/PRs from humans. If it "looks like claude" in that it's overly verbose (in code or comments), missing tests, etc then it should be rejected for lack of merits. If the only indication is "this user fixed 10 bugs in an hour" and the PRs are otherwise fine on the me…
Why? Because the onus of determining fitness of purpose and correctness has to be done by someone. So if a PR is buggy and/or lacking in test coverage, but was made by a contributor making an honest effort, then experienced contributors can help educate the person as to what is missing or needs to be considered. Ultimately, this is a form of apprenticeship.
Contrast that with someone using an LLM to produce the exact same PR. Who can be mentored? Who can be referred to materials which can deepen requisite knowledge?
Re: NetBSD 9.5 released and EOL for NetBSD-9
#14Earlier quoted context omitted.
> It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds. Equating LLM generated code to "lab-grown diamonds" is disingenuous at best. > Someone would be happy to take them and [be] none the wiser. If the quality of GenAI PRs were equivalent to those authored by experienced contributors, then there would not be as many GenAI PR bans in FOSS…
The quality of GenAI PRs scales with the driver. Many are low-effort, ill-considered, overly verbose and otherwise bad. I've seen decades of similar patches/PRs from humans. If it "looks like claude" in that it's overly verbose (in code or comments), missing tests, etc then it should be rejected for lack of merits. If the only indication is "this user fixed 10 bugs in an hour" and the PRs are otherwise fine on the me…
You don't know that they are low effort PRs until you expend time and energy, while in the meantime more important PRs might be in the queue that can potentially never get seen if the submitter decides to keep that rate up for a week.
The project will die before you get to other's PRs decades later.
The answer might be to RR reviews from submitters and not treat PRs as first come first served.
That way other submitters don't have their PRs blocked.
Re: NetBSD 9.5 released and EOL for NetBSD-9
#15Earlier quoted context omitted.
It is a backup machine for important files. Plus testing items I develop to see how they run in limited environments.
Just wondering how does that fair over a vm or container that has similar limitations?
But I saw somewhere someone is working on a jail like item for NetBSD.
Re: NetBSD 9.5 released and EOL for NetBSD-9
#16Oldest one: VAX780 from 1978(!!!). First 32bit xpu with mmu
Re: NetBSD 9.5 released and EOL for NetBSD-9
#17Earlier quoted context omitted.
The quality of GenAI PRs scales with the driver. Many are low-effort, ill-considered, overly verbose and otherwise bad. I've seen decades of similar patches/PRs from humans. If it "looks like claude" in that it's overly verbose (in code or comments), missing tests, etc then it should be rejected for lack of merits. If the only indication is "this user fixed 10 bugs in an hour" and the PRs are otherwise fine on the me…
The problem is "This user submits in 60 minutes enough PRs to keep us busy for a week". You don't know that they are low effort PRs until you expend time and energy, while in the meantime more important PRs might be in the queue that can potentially never get seen if the submitter decides to keep that rate up for a week. The project will die before you get to other's PRs decades later. The answer might be to RR revie…
Re: NetBSD 9.5 released and EOL for NetBSD-9
#18Re: NetBSD 9.5 released and EOL for NetBSD-9
#19NetBSD holds record for most supported architectures. Like 50 diffrent, while Linux like maybe 20... Oldest one: VAX780 from 1978(!!!). First 32bit xpu with mmu
Re: NetBSD 9.5 released and EOL for NetBSD-9
#20Earlier quoted context omitted.
The problem is "This user submits in 60 minutes enough PRs to keep us busy for a week". You don't know that they are low effort PRs until you expend time and energy, while in the meantime more important PRs might be in the queue that can potentially never get seen if the submitter decides to keep that rate up for a week. The project will die before you get to other's PRs decades later. The answer might be to RR revie…
I’ve been in your same situation for a long time now and I’ve been building a platform to help myself navigate through so many PRs, and doing all of this on github wasn’t sustainable, you could try it out and see if it helps your situation. https://pyor.review