Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 May 2024 20:18:54 +0200
From:      Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
To:        freebsd-net@freebsd.org
Subject:   Re: removing RIP/RIPng (routed/route6d)
Message-ID:  <1613e4c8-c102-45a8-9f8e-3b5e7fd09e25@plan-b.pwste.edu.pl>
In-Reply-To: <CAHu1Y712dPK6nnwfKwV_UtbyuQ9GUpP=OBQ%2B-s_39psZobvWrg@mail.gmail.com>
References:  <CAFYkXjmMFuL0rtpYUO=-TTEOxiu795sxtATg6RGdHjMhHeoYew@mail.gmail.com> <MN0PR84MB3024D8CAF5915733D5F7B537C0EC2@MN0PR84MB3024.NAMPRD84.PROD.OUTLOOK.COM> <CAHu1Y712dPK6nnwfKwV_UtbyuQ9GUpP=OBQ%2B-s_39psZobvWrg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <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
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Today Michael Sierchio wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHu1Y712dPK6nnwfKwV_UtbyuQ9GUpP=OBQ+-s_39psZobvWrg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">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.
        <div><br>
        </div>
      </div>
    </blockquote>
    <p>FreeBSD is a comprehensive OS, and most users still do appreciate
      this feature.<br>
    </p>
    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.  <br>
    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 ?<br>
    <p><br>
    </p>
    <p>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.</p>
    <p>Cheers<br>
    </p>
    <p>Marek<br>
    </p>
    <blockquote type="cite"
cite="mid:CAHu1Y712dPK6nnwfKwV_UtbyuQ9GUpP=OBQ+-s_39psZobvWrg@mail.gmail.com"><br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, May 15, 2024 at
          1:01 PM John Howie &lt;<a href="mailto:john@thehowies.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">john@thehowies.com</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
          <br>
          Sent from my iPhone<br>
          <br>
          &gt; On May 15, 2024, at 07:40, Tomek CEDRO &lt;<a
            href="mailto:tomek@cedro.info" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">tomek@cedro.info</a>&gt;
          wrote:<br>
          &gt; <br>
          &gt; On Wed, May 15, 2024 at 4:20 PM Scott &lt;<a
            href="mailto:uatka3z4zagp@thismonkey.com" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">uatka3z4zagp@thismonkey.com</a>&gt;
          wrote:<br>
          &gt;&gt;&gt; On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi
          Winter wrote:<br>
          &gt;&gt;&gt; (..)<br>
          &gt;&gt;&gt; i'd like to submit a patch to remove both of
          these daemons from src.  if<br>
          &gt;&gt;&gt; there's some concern that people still want to
          use the BSD<br>
          &gt;&gt;&gt; implementation of routed/route6d, i'm also
          willing to submit a port such<br>
          &gt;&gt;&gt; as net/freebsd-routed containing the old code, in
          a similar way to how<br>
          &gt;&gt;&gt; the removal of things like window(1) and
          telnetd(8) were handled.<br>
          &gt;&gt; <br>
          &gt;&gt; I use RIPv2 for it's simplicity and small memory and
          CPU requirements.  It<br>
          &gt;&gt; has its place and shouldn't be considered "legacy"
          despite its shortcomings.<br>
          &gt;&gt; It's not uncommon for vendors like Cisco to produce
          "basic" feature sets of<br>
          &gt;&gt; IOS that do not include any link-state protocols.<br>
          &gt;&gt; <br>
          &gt;&gt; Anyway, I'm a user, albeit a small user, of RIP and
          wouldn't object to its<br>
          &gt;&gt; removal from FreeBSD if there were a small footprint
          alternative.  I've used<br>
          &gt;&gt; FRR and VyOS a bit and they are overkill as
          replacements.<br>
          &gt;&gt; <br>
          &gt;&gt; Your email doesn't justify its removal other than to
          say you are unconvinced<br>
          &gt;&gt; of the value of shipping it.  As a user I definitely
          see the value.  I<br>
          &gt;&gt; understand that there is always a cost to providing
          code, but that wasn't<br>
          &gt;&gt; suggested as a reason.  All APIs, modules, utilities,
          etc. need to regularly<br>
          &gt;&gt; justify their presence in the OS.<br>
          &gt;&gt; <br>
          &gt;&gt; If it must be removed, is there any way to fork the
          FreeBSD routed and<br>
          &gt;&gt; route6d to a port?  Or would that defeat the purpose
          of removing it in the<br>
          &gt;&gt; first place?<br>
          &gt; <br>
          &gt; Yeah, where did that recent trend came to FreeBSD to
          remove perfectly<br>
          &gt; working code??<br>
          &gt; <br>
          &gt; There are more and more ideas in recent times like this.<br>
          &gt; <br>
          &gt; Architectures removal, drivers removal, backward
          compatibility<br>
          &gt; removal. While basic functions become unstable and
          unreliable. Looks<br>
          &gt; more like diversion and sabotage than progress.<br>
          &gt; <br>
          &gt; If anything is about to be moved out from SRC for a
          really good reason<br>
          &gt; it should be available in ports and not in /dev/null.<br>
          &gt; </blockquote>
      </div>
    </blockquote>
  </body>
</html>

--------------0iQnbKUC48Wd0AISOHCc1jVr--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1613e4c8-c102-45a8-9f8e-3b5e7fd09e25>