Call to delay EOL of 11.x -> Re: OS to replace FreeBSD

[Mohammad Noureldin]

Hi Jerry,

I do agree with others not to talk about the same problem on more than one
thread. This is not helping you or anyone else.

As for your reply, I was not talking about installing FreeBSD directly, I
was talking about one of the proposed ways to test, by installing FreeBSD
in a VM to see if you would get the same issues. IIUC, this can help more
in  understanding and solving the problem.

On Sat, Mar 20, 2021, 14:33 Jerry <jerry at seibercom.net> wrote:

> On Sat, 20 Mar 2021 13:45:13 +0100, Mohammad Noureldin stated:
> >Hi Jerry,
> >
> >On Sat, Mar 20, 2021, 13:38 Jerry <jerry at seibercom.net> wrote:
> >
> >> On Sat, 20 Mar 2021 12:30:15 +0100, Mohammad Noureldin stated:
> >> >Hi,
> >> >
> >> >On Sat, Mar 20, 2021, 10:00 @lbutlr <kremels at kreme.com> wrote:
> >> >
> >> >> On 19 Mar 2021, at 10:10, freebsd at johnea.net wrote:
> >> >> > To anyone who has read the bug report, this is clearly a
> >> >> > serious
> >> >> regression issue on certain USB (probably 3) host controller
> >> >> hardware.
> >> >>
> >> >> I've read the bug report and all the replies and it is clearly a
> >> >> flaw in the controller. It is providing an invalid ID.
> >> >>
> >> >
> >> >If that's the case, I am curious how other Unix-Like Operating
> >> >Systems manage to work on the same HW ?
> >>
> >> There are a number of possibilities.
> >>
> >> 1) They have better programmers that can handle abnormalities.
> >>
> >> 2) They realize that there are always going to be flaws in software
> >> and hardware and are smart enough to work around it.
> >>
> >> This is of course assuming that the actual problem is a defective
> >> controller that every other OS can handle correctly. If, and this is
> >> assuming that is correct, then why doesn't FreeBSD just code what the
> >> defective controller is allegedly sending and accept it?
> >>
> >> The simple fact the the code worked in versions prior to 12.x makes
> >> this excuse that the controlled is defective highly suspect.
> >>
> >
> >Hi Jerry,
> >
> >I do understand your frustrations, but if you allow me, it is not a
> >reason to attack the FreeBSD community and it's developers. Let's
> >please focus on facts and possible solutions.
> >
> >As stated in this thread (and another one), did you have time to try
> >any of the proposed tests ?
> >
> >Looking forward to your reply
>
> I CANNOT install it, so I am unsure of how to build a custom kernel.
> Then, assuming I could build a custom kernel, I would not be able to
> use the "freebsd update" utility.  So, to put it in the vernacular,
> "I am fucked if I do, and fucked if I don't". Not a great choice of
> options. I am investigating it though. I got some help from a friend on
> the Microsoft forum who told me he was almost positive I could install
> Windows 10 PRO, then Hyper V and run FreeBSD 12.x or 13.x from there.
> He is polling other users to see if they have had success with the same
> equipment I process. The one very apparent advantage is that I would be
> able to take advantage of Intel's Optane Memory and Storage. As far as
> I can tell, FreeBSD does not support that architecture.
>
> In computing, the robustness principle is a design guideline for software:
>
> Be conservative in what you do, be liberal in what you accept from
> others (often reworded as "Be conservative in what you send, be liberal
> in what you accept"). The principle is also known as Postel's law,
> after Jon Postel, who wrote in an early specification of TCP:
>
> TCP implementations should follow a general principle of robustness: be
> conservative in what you do, be liberal in what you accept from others.
> In other words, programs that send messages to other machines (or to
> other programs on the same machine) should conform completely to the
> specifications, but programs that receive messages should accept
> non-conformant input as long as the meaning is clear.
>
> Among programmers, to produce compatible functions, the principle is
> also known in the form be contravariant in the input type and covariant
> in the output type.
>
> While this is not a TCP issue directly, the same general principal is
> still relevant.
>
> --
> Jerry
>
>
>