On Wed, May 15, 2024 at 1:01=E2=80=AFPM John Howie <john@thehowies.com> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">I use RIP all the time. Re= moving it would be a pain. What is the justification? Moving it to ports is= an option, but now we have to compile, distribute, and install it.

Sent from my iPhone

> On May 15, 2024, at 07:40, Tomek CEDRO <tomek@cedro.info> wrote:
>
> =EF=BB=BFOn Wed, May 15, 2024 at 4:20=E2=80=AFPM Scott <uatka3z4zagp@thismonk= ey.com> wrote:
>>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote: >>> (..)
>>> i'd like to submit a patch to remove both of these daemons= from src.=C2=A0 if
>>> there's some concern that people still want to use the BSD=
>>> implementation of routed/route6d, i'm also willing to subm= it a port such
>>> as net/freebsd-routed containing the old code, in a similar wa= y to how
>>> the removal of things like window(1) and telnetd(8) were handl= ed.
>>
>> I use RIPv2 for it's simplicity and small memory and CPU requi= rements.=C2=A0 It
>> has its place and shouldn't be considered "legacy" d= espite its shortcomings.
>> It's not uncommon for vendors like Cisco to produce "basi= c" feature sets of
>> IOS that do not include any link-state protocols.
>>
>> Anyway, I'm a user, albeit a small user, of RIP and wouldn'= ;t object to its
>> removal from FreeBSD if there were a small footprint alternative.= =C2=A0 I've used
>> FRR and VyOS a bit and they are overkill as replacements.
>>
>> Your email doesn't justify its removal other than to say you a= re unconvinced
>> of the value of shipping it.=C2=A0 As a user I definitely see the = value.=C2=A0 I
>> understand that there is always a cost to providing code, but that= wasn't
>> suggested as a reason.=C2=A0 All APIs, modules, utilities, etc. ne= ed to regularly
>> justify their presence in the OS.
>>
>> If it must be removed, is there any way to fork the FreeBSD routed= and
>> route6d to a port?=C2=A0 Or would that defeat the purpose of remov= ing it in the
>> first place?
>
> Yeah, where did that recent trend came to FreeBSD to remove perfectly<= br> > working code??
>
> There are more and more ideas in recent times like this.
>
> Architectures removal, drivers removal, backward compatibility
> removal. While basic functions become unstable and unreliable. Looks > more like diversion and sabotage than progress.
>
> If anything is about to be moved out from SRC for a really good reason=
> it should be available in ports and not in /dev/null.
>