Re: removing RIP/RIPng (routed/route6d)

i think it's not too soon for the bsd community to become less 
reactionary. (yes, i know that's ironic coming from me.)

https://nomadbsd.org/

i'd like freebsd to be fit for a lot of purposes. a complete OS is one 
of those that i will use the most. but not the only one for me, and not 
the only one for the community.

take deep breaths.

re:

John Howie wrote on 2024-05-15 19:04:
> FreeBSD (and BSD Unix in general) has a rich history of being a 
> “complete” OS – kernel and userland. If there was really a demand for a 
> minimalist version of FreeBSD, why have people not forked FreeBSD and 
> created it by now? There is also nanobsd, as an option, for those that 
> want minimalist installs (yes, I know it is meant for embedded systems, 
> but it works).
> 
> I think we need to stop trying to find solutions for non-existent problems.
> 
> *From: *[email protected] <[email protected]> on 
> behalf of Marek Zarychta <[email protected]>
> *Date: *Wednesday, May 15, 2024 at 11:19 AM
> *To: *[email protected] <[email protected]>
> *Subject: *Re: removing RIP/RIPng (routed/route6d)
> 
> 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 <[email protected]
>     <mailto:[email protected]>> 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 <[email protected]
>         <mailto:[email protected]>> wrote:
>          >
>          > On Wed, May 15, 2024 at 4:20 PM Scott
>         <[email protected]
>         <mailto:[email protected]>> 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.
>          >
> 


-- 
P Vixie