NetBSD 9.5 released and EOL for NetBSD-9

Posted by jaypatelani 1 day ago

Counter150Comment16OpenOriginal

Comments

Comment by jmclnx 1 day ago

I need to get around and upgrade an old mini-tower with an AMD-586 w/512MB memory from 9.3 to 11.0, I may wait for 11.1.

Comment by soupbowl 1 day ago

What do you use that low spec machine for?

Comment by jmclnx 1 day ago

It is a backup machine for important files. Plus testing items I develop to see how they run in limited environments.

Comment by throwaway270925 17 hours ago

Interesting, whats your backup process, of you mind sharing?

Comment by 0dayz 1 day ago

Just wondering how does that fair over a vm or container that has similar limitations?

Comment by jmclnx 1 day ago

I do not like using VMs and containers, I do like FreeBSD jails. Plus my main machine is around 12 or 13 years old, so I avoid VMs on it.

But I saw somewhere someone is working on a jail like item for NetBSD.

Comment by soupbowl 1 day ago

Cool, was just curious.

Comment by iberator 22 hours ago

NetBSD holds record for most supported architectures. Like 50 diffrent, while Linux like maybe 20...

Oldest one: VAX780 from 1978(!!!). First 32bit xpu with mmu

Comment by 16 hours ago

Comment by 3qajsh17 1 day ago

[flagged]

Comment by emidln 1 day ago

If you think you can identify frontier model-generated planned and reviewed c/c++ from human-generated planned and reviewed c/c++, I've got some bad news for you.

The "no slop" policy is the same as it ever was: garbage has to make it through patch code review. If an LLM wrote it rather than a human and it passes patch review, it's fine. Rejecting features or fixes because a probabilistic algorithm said "should look like this" feels a lot like rejecting c/c++ because you read Intel's docs and have a hex editor.

Edit: s/like like/look like/

Comment by a31ahg 1 day ago

[flagged]

Comment by sigseg1v 1 day ago

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.

Comment by AdieuToLogic 1 day ago

> 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 operating system repositories.

Comment by emidln 1 day ago

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 merits, rejecting the PRs because an LLM wrote them is the same as rejecting them because you know they're from an emacs user.

Comment by lelanthran 1 day ago

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 reviews from submitters and not treat PRs as first come first served.

That way other submitters don't have their PRs blocked.

Comment by othmanosx 18 hours ago

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

Comment by lelanthran 4 hours ago

I don't think netbsd uses github.

Comment by AdieuToLogic 1 day ago

Like many things in complex projects such as operating systems, accepting PRs is not as simple as "if this one use of a tool works, why not accept it?"

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?