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 <to...@cedro.info> wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott <uatka3z4z...@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. >
