From nobody Wed May 15 17:22:58 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vfg6x166yz49vwj for ; Wed, 15 May 2024 17:23:37 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vfg6w6DpBz4g2D for ; Wed, 15 May 2024 17:23:36 +0000 (UTC) (envelope-from kudzu@tenebras.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6f45f1179c3so6653003b3a.3 for ; Wed, 15 May 2024 10:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20230601.gappssmtp.com; s=20230601; t=1715793815; x=1716398615; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CRQ6tg7pEWA/WpFee8ZXHMDLiWmupIfhgHygCWPRfEo=; b=HBdvZz2yq9BUFIzLX8kkEjP3fWkrlJPMP06NvJ2ar3RMB+9/isVKui+mYnN+8/z6Dw PEaJw8g4x18AnQ5FxpiC97B99YQpWMrtwJ/aZU6JxFJ6q9mX+WswC7CzexkOjA1W3kU3 VcHrDJ8QPYEFnPE/BMGaxleS/Sx4y1v/q9PQO6eZWtGUebBP2xTaXg62tTB14jabFQ95 mQKAKDUEHw+r843waxtWEj/FSU25FKXQXtcNMWkZr8xBhz2yMQIcH8RI7vDCvUo+jH/R NwWjxSLTq8oa+qSwQbW222OArQ0ssH+9HWNLD9elg9c4kGarRv1kKr6fjWP4wBQ39cSR Sz5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715793815; x=1716398615; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CRQ6tg7pEWA/WpFee8ZXHMDLiWmupIfhgHygCWPRfEo=; b=q2rfSqjSVXSAazbERg9hZd0/0nFrctWhWWEzJpkdlmaRc3MBFW13K1KEpVp7GNLhGb MT9fJS0xPbIjPWBg0abU8IpulF/Wnr3X3Nx6ug3/wNVa4NuV0+vNJSZUxwAwyMQd0JX3 Nz1QIxbDGur1EXWZ5bAERRNVevBZDku0Fd6u6TbvgYBH4c0+uMt89KJBcqzL+qag97uj QbdCWDzla/8KLXN7FovhuxlU69j+FunmDXbjEju+O5E+Mv1Ee32HbkfHWV7/DIhdBq5c WVScc2jZeSvbAVgAQYEXXB8re/c0WfazxLPxKhL0eAs/9dseQ4DmDyxLVILFH2H/bnm4 5rhw== X-Forwarded-Encrypted: i=1; AJvYcCUnbqT4AXSGLYUhDTflffGwEbdL90GDkGWiCN/hbU+qxPiu8U4z6yYNo9dnD3F50YyPhLbWjKY716VsahtyyIo= X-Gm-Message-State: AOJu0YxOPZi4IYdeW34YVwbmWqbH/ERTiLrr71MZumQ4ChMNhWIZlzX6 P/LO0oXzgn9Mq0eT33mQ2q0g1hXo/O1f4P6AmCa2aWwsv5SaX6bxe7NsUHtKLF7rti+pu4awy1g cj7510K10+OhBvIrT1SnFL94ArS1uw18vA7AVrRfWvPS8Az4H X-Google-Smtp-Source: AGHT+IEb4qfwkNaZNBtVnBNnDImLsgo1x5C5zocQN0J5igVOC/hfFTKTBJY/gyalX4J03QONisFQf6RN8obNPdJrt9c= X-Received: by 2002:a05:6a20:f397:b0:1af:d0bc:d149 with SMTP id adf61e73a8af0-1afde0a8d01mr16321309637.6.1715793814890; Wed, 15 May 2024 10:23:34 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Sierchio Date: Wed, 15 May 2024 13:22:58 -0400 Message-ID: Subject: Re: removing RIP/RIPng (routed/route6d) To: John Howie Cc: Tomek CEDRO , Scott , net@freebsd.org, Lexi Winter Content-Type: multipart/alternative; boundary="000000000000d8495206188160b7" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Vfg6w6DpBz4g2D --000000000000d8495206188160b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is an argument to be made that all such components of the "base" system should be packages, and managed that way. That would facilitate removal or addition of things like MTAs, Route daemons for various protocols, etc. and permit them to be updated independent of the base system. Too much is included by default in Base. On Wed, May 15, 2024 at 1:01=E2=80=AFPM John Howie wro= te: > I use RIP all the time. Removing it would be a pain. What is the > justification? Moving it to ports is an option, but now we have to compil= e, > distribute, and install it. > > Sent from my iPhone > > > On May 15, 2024, at 07:40, Tomek CEDRO wrote: > > > > =EF=BB=BFOn Wed, May 15, 2024 at 4:20=E2=80=AFPM Scott > 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. > if > >>> there's some concern that people still want to use the BSD > >>> implementation of routed/route6d, i'm also willing to submit a port > such > >>> as net/freebsd-routed containing the old code, in a similar way to ho= w > >>> the removal of things like window(1) and telnetd(8) were handled. > >> > >> I use RIPv2 for it's simplicity and small memory and CPU requirements. > It > >> has its place and shouldn't be considered "legacy" despite its > shortcomings. > >> It's not uncommon for vendors like Cisco to produce "basic" 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. I'v= e > used > >> FRR and VyOS a bit and they are overkill as replacements. > >> > >> Your email doesn't justify its removal other than to say you are > unconvinced > >> of the value of shipping it. As a user I definitely see the value. I > >> understand that there is always a cost to providing code, but that > wasn't > >> suggested as a reason. All APIs, modules, utilities, etc. need 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? Or would that defeat the purpose of removing it in > the > >> first place? > > > > Yeah, where did that recent trend came to FreeBSD to remove perfectly > > 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. > > > > --000000000000d8495206188160b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is an argument to be made that all such components o= f the "base" system should be packages, and managed that way.=C2= =A0 That would facilitate removal or addition of things like MTAs, Route da= emons for various protocols, etc.=C2=A0 and permit them to be updated indep= endent of the base system.=C2=A0 Too much is included by default in Base.

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.
>

--000000000000d8495206188160b7--