From nobody Wed May 15 18:18:54 2024 X-Original-To: freebsd-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 4VfhM05XdDz4B1Kr for ; Wed, 15 May 2024 18:19:08 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VfhLz3ZHGz4nBY for ; Wed, 15 May 2024 18:19:07 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=v9WGC+TQ; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 44FIItSd091049 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 15 May 2024 20:18:56 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1715797137; bh=BxqipdmIhT/oHmwK0b8SpqgKRPR/r6nWCdl6ZtqrnSk=; h=Date:Subject:To:References:From:In-Reply-To; b=v9WGC+TQL9kBYodI1y2gKjZZ9gxmqTJo9jtVL1JnkkqtA0qjj5ltfqU+gqOdhrVdI 7oOKH82miTcQuWKDkoU36JTB3sZD1omJaW33h5zA2p2ZqD4Y+VOUKxI0yBdVYqDY8n wifJK/D/NJyc/AcGBxjzrcdPzT3ptnCVBKc8A96D4UlzXVgF1402ZyGZ6y6Gq82qQs kk99U9Ohf/EB7Ok98jInnz7+U/ggoThglIn8Rd6K78PtHXpfNh2cxb0QE1zWCC87Y2 GXBz7cV/Ekx13pLRhJgFyCTF1Uzcg46MFRVWOBqithicEsAvRGM/W+2vu0aUL484Zq oqaHATX9Wm5AA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------0iQnbKUC48Wd0AISOHCc1jVr" Message-ID: <1613e4c8-c102-45a8-9f8e-3b5e7fd09e25@plan-b.pwste.edu.pl> Date: Wed, 15 May 2024 20:18:54 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: removing RIP/RIPng (routed/route6d) To: freebsd-net@freebsd.org References: Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+] X-Rspamd-Queue-Id: 4VfhLz3ZHGz4nBY This is a multi-part message in MIME format. --------------0iQnbKUC48Wd0AISOHCc1jVr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Today Michael Sierchio wrote: > 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. > FreeBSD is a comprehensive OS, and most users still do appreciate this feature. I remember that we had also RCS tools in the base system, they got purged (moved to the ports tree really), most users are fine with it, but for managing single config files RCS is still the best-suited versioning system. We still have ftpd(8), but it was almost removed, there was a strong battle on the mailing list to preserve it. FTP protocol is as old as BSD, but it's still valid and, so far not deprecated. A similar story was with smbfs(5). The same probably applies to RIP/RIPng. What if we would better remove LLVM from the base if the system is bloated ? LLVM needs frequent updates and keeping it in base is far more risky in terms of system security than keeping RIP daemons. Why do we still have odd tools like biff(1) in the base ? On the other hand, for a significant share of the user base, the more tiny the OS is, the better. The transition to PkgBase should fulfill user needs, especially those, who want a minimalist OS. So please, go ahead and switch to PgkBase if your FreeBSD system contains undesired software. Cheers Marek > > On Wed, May 15, 2024 at 1:01 PM John Howie wrote: > > 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 > compile, distribute, and install it. > > Sent from my iPhone > > > On May 15, 2024, at 07:40, Tomek CEDRO wrote: > > > > On Wed, May 15, 2024 at 4:20 PM 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 how > >>> 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'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 > 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. > > > --------------0iQnbKUC48Wd0AISOHCc1jVr Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Today Michael Sierchio wrote:
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.

FreeBSD is a comprehensive OS, and most users still do appreciate this feature.

I remember that we had also RCS tools in the base system, they got purged (moved to the ports tree really), most users are fine with it, but for managing single config files RCS is still the best-suited versioning system. We still have ftpd(8), but it was almost removed, there was a strong battle on the mailing list to preserve it. FTP protocol is as old as BSD, but it's still valid and, so far not deprecated. A similar story was with smbfs(5). The same probably applies to RIP/RIPng.  
What if we would better remove LLVM from the base if the system is bloated ? LLVM needs frequent updates and keeping it in base is far more risky in terms of system security than keeping RIP daemons. Why do we still have odd tools like biff(1) in the base ?


On the other hand, for a significant share of the user base, the more tiny the OS is, the better. The transition to PkgBase should fulfill user needs, especially those, who want a minimalist OS. So please, go ahead and switch to PgkBase if your FreeBSD system contains undesired software.

Cheers

Marek


On Wed, May 15, 2024 at 1:01 PM John Howie <john@thehowies.com> wrote:
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 compile, distribute, and install it.

Sent from my iPhone

> On May 15, 2024, at 07:40, Tomek CEDRO <tomek@cedro.info> wrote:
>
> On Wed, May 15, 2024 at 4:20 PM Scott <uatka3z4zagp@thismonkey.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.  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 how
>>> 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'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 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.
>
--------------0iQnbKUC48Wd0AISOHCc1jVr--