> I could get behind “converge to a fixed scope, and polish relentlessly” as the primary ethos.
> Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
By OS do you mean just the kernel or also the userspace?
Then I think the challenge is to determine what gets included under the purview of relentless polishing.
Assuming you mean just the kernel, then probably bug fixes are included. But what about drivers for new hardware? And when researchers at Stanford develop a new file system algorithm with foo bar baz properties? Or a new scheme for sandboxing user programs?
Maybe all new features in new Major version? New FS=Next. But drivers should be buildable by the HW vendor right? And shouldn't the next kernel version be not crazy-hard to port the driver?
I don’t think I understand the (many) purpose(s) of OS versioning. Vendors use them to make specific maintenance commitments? “We will continue to make bug fixes for version XYZ until 2025.”
And if end users care about a particular program, “Okay, version XZY of my favorite OS supports programs A and B.”?
> But drivers should be buildable by the HW vendor right?
The vendor may not create a driver for this OS. “Only 10k people use this OS, therefore it’s likely not profitable for us to make a driver for it.”
> Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
By OS do you mean just the kernel or also the userspace?
Then I think the challenge is to determine what gets included under the purview of relentless polishing.
Assuming you mean just the kernel, then probably bug fixes are included. But what about drivers for new hardware? And when researchers at Stanford develop a new file system algorithm with foo bar baz properties? Or a new scheme for sandboxing user programs?