Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)
- Reply: Adrian Chadd : "Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)"
- Reply: Olivier Certner : "Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)"
- In reply to: Olivier Certner : "Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 21 Jan 2026 16:28:36 UTC
On 1/21/26 05:34, Olivier Certner wrote: > > Some people in this thread are apparently getting emotional with this topic of potentially retiring 4BSD to the point where they cannot even grasp simple propositions. You may have your reasons, I certainly don't dispute that. But at least I would like my real message to be understood for what it is and that you stop talking past me. I don't see emotional responses. I see responses expressing disappointment with a plan to remove 4BSD. > > So I'll try again with another formulation, even if it is redundant as it is logically implied by what I've already said. Please read it carefully: > I do not intend to retire 4BSD if (we know for sure that) there are workloads where it performs significantly better than ULE. > > Does that reassure you? Why does 4BSD have to be**significantly better** than ULE? What if 4BSD performs on-par with ULE? > >> As our time to delivery will increase should we be required to create additional local patches to circumvent 4BSD removal. >> Which would be a long term commitment. > > I hope you understand this as an argument for actually testing ULE and especially responding to future test calls in the area, as doing so will likely cost you much less than keeping 4BSD around by yourself. > In another response, you noted that you're concentrating on testing ULE. That's fine. But, you also wrote "I did not do that for 4BSD, just basic smoke tests and that's all." Again, that's fine. There is only so much time in a day. But, to draw the conclusion that ULE is better than 4BSD, and therefore 4BSD should be removed in FreeBSD 16 seems a bit suspect. -- steve