Re: removing RIP/RIPng (routed/route6d)
<> That's been a very workable system. p vixie On May 17, 2024 21:32, "Rodney W. Grimes" wrote: > Scott writes: > > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation > > provide the rules under which code is added or removed from base and then > > we'd all be the wiser. > > The FreeBSD Foundation does not set project policy, the FreeBSD Core > Team does. Sadly that was never my intent when I created the original "Core", the core team was to help the developers in setting project policy based on there inputs and interactions, not to just elect some group of people and then bow down to them for all decisions. The DEVELOPERS as a whole is who should be setting all project policies. -- Rod Grimes rgri...@freebsd.org
Re: removing RIP/RIPng (routed/route6d)
> Scott writes: > > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation > > provide the rules under which code is added or removed from base and then > > we'd all be the wiser. > > The FreeBSD Foundation does not set project policy, the FreeBSD Core > Team does. Sadly that was never my intent when I created the original "Core", the core team was to help the developers in setting project policy based on there inputs and interactions, not to just elect some group of people and then bow down to them for all decisions. The DEVELOPERS as a whole is who should be setting all project policies. -- Rod Grimes rgri...@freebsd.org
Re: removing RIP/RIPng (routed/route6d)
Scott writes: > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation > provide the rules under which code is added or removed from base and then > we'd all be the wiser. The FreeBSD Foundation does not set project policy, the FreeBSD Core Team does. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: removing RIP/RIPng (routed/route6d)
Scott: > I'm never sure whether to respond to sophistry and rhetoric, but why not, > let's play: my intention with this post was not to engage in sophistry, but to explain (or justify) the reasoning behind my proposal to remove RIP/RIPng, since you seemed to be asking for more details on that. i apologise if it came across as unnecessarily rhetorical, but i often find the easiest way to explain my reasoning behind something is by example. perhaps this is a personal flaw :-) in any case it sounds like you're content with routed being moved to a port rather than banished entirely. my assumption in the original mail was that this would happen anyway (assuming it at least 1 remaining user) but perhaps i wasn't clear enough about that.
Re: removing RIP/RIPng (routed/route6d)
On Thu, May 16, 2024 at 02:02:52PM +0100, Lexi Winter wrote: > Scott: > > 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. > > i imagined there are still people using RIP, so i only proposed removing > it since there are several alternatives available. > > > 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. > > Cy has already created ports for these (although i haven't tested them > yet): > > https://cgit.freebsd.org/ports/tree/net/freebsd-routed > https://cgit.freebsd.org/ports/tree/net/freebsd-route6d > > so if you like routed/route6d, you can continue using them even after > their removal. that said, i'd also suggest considering net/bird2; it's > smaller than FRR and (imo) nicer to manage, not to mention much more > maintained than routed is. > > > 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. > > let me turn this around and ask the opposite question: if FreeBSD didn't > currently ship RIP/RIPng in the base operating system, would a request > to add an implementation of it be considered? > > almost anything would be useful for someone, somewhere. for example, > i'd quite like to see a basic Wayland compositor (such as hikari) and a > terminal emulator in the base system, because that's a bit nicer to use > than vt(4) if you just need to occasionally manage a system via the > framebuffer console. i feel fairly confident to say that this would be > useful to a greater number of people than an implementation of RIP. > > but i wouldn't propose actually doing this in base, because i can fairly > easily install this from ports, and the cost of maintaining the code in > base would outweight the advantage of not having to type 'pkg install > hikari'. > > similarly for RIP/RIPng, if routed were currently in ports and not in > base, there would be very little justification for integrating it into > base when someone can just install it from the port. > > this was different back in the days when routed was first created, > because there was no ports system and RIP was common enough that it was > useful to users -- along with the fact that 4BSD was effectively the > reference implementation of IP and sockets, so shipping RIP was > reasonable in that context. > > so the question for me is not whether it should be in base at all (it > clearly shouldn't be, by today's standards), but does the inconvenience > to users of removing it outweigh the cost of maintaining the code > forever? i don't claim to have any particular expertise here, so people > might reasonably disagree, but in my opinion, given the small number of > users, the advanced notice period (15.0-RELEASE) and the ease of > addressing the problem (pkg install freebsd-routed) the answer is yes. > > someone elsethread mentioned that they expect FreeBSD to be a "complete > operating system". what does this mean in practice? many people expect > a complete operating system to include a GUI, yet FreeBSD hasn't shipped > X in the base system for quite a while. should we put X back into base? > > the most sensible way to address this, to me, seems to be that the base > OS should include things which are a) widely used, b) not available > elsewhere, and c) worth the maintenance cost. for example, the kernel > is in base, because there's no FreeBSD without the kernel. /bin/sh is > in base because the OS would be unusable without it, even though you > can install other shells from ports. /etc/rc is in base because an > rc-system is required and /etc/rc is the only one that exists for > FreeBSD. > > fetch(1) is in base even though you can install equivalent software > (e.g., cURL) from ports, so you could make an argument that it should be > moved to ports. however, fetch is useful for both bsdinstall and for > many custom post-installation tasks that need an HTTP client, and > attempting to remove it would be very disruptive. > > cron(8) is in base even though there are other cron implementations, > because widely-used parts of the the base system (e.g., periodic(8)) > depend on cron for basic functionality; removing cron would also require > removing this functionality, and that would be a significant loss to > users with no obvious replacement. > > but routed is not widely used in general, either by
Re: removing RIP/RIPng (routed/route6d)
On Thu, May 16, 2024 at 3:03 PM Lexi Winter wrote: > (..) > almost anything would be useful for someone, somewhere. for example, > i'd quite like to see a basic Wayland compositor (such as hikari) and a > terminal emulator in the base system, because that's a bit nicer to use > than vt(4) if you just need to occasionally manage a system via the > framebuffer console. i feel fairly confident to say that this would be > useful to a greater number of people than an implementation of RIP. If that takes around 10MB its worth considering.. may be helpful for visual oci management :-) > would people objecting to the removal of routed also advocate for > putting window(1) back into base? (this is not a rhetorical question, > 'yes' is a perfectly reasonable answer.) The subtle difference between "removing RIP/RIPng (routed/route6d)" and "[base->ports] moving RIP/RIPng (routed/route6d) to ports" :-) Have a good day folks :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: removing RIP/RIPng (routed/route6d)
Scott: > 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. i imagined there are still people using RIP, so i only proposed removing it since there are several alternatives available. > 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. Cy has already created ports for these (although i haven't tested them yet): https://cgit.freebsd.org/ports/tree/net/freebsd-routed https://cgit.freebsd.org/ports/tree/net/freebsd-route6d so if you like routed/route6d, you can continue using them even after their removal. that said, i'd also suggest considering net/bird2; it's smaller than FRR and (imo) nicer to manage, not to mention much more maintained than routed is. > 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. let me turn this around and ask the opposite question: if FreeBSD didn't currently ship RIP/RIPng in the base operating system, would a request to add an implementation of it be considered? almost anything would be useful for someone, somewhere. for example, i'd quite like to see a basic Wayland compositor (such as hikari) and a terminal emulator in the base system, because that's a bit nicer to use than vt(4) if you just need to occasionally manage a system via the framebuffer console. i feel fairly confident to say that this would be useful to a greater number of people than an implementation of RIP. but i wouldn't propose actually doing this in base, because i can fairly easily install this from ports, and the cost of maintaining the code in base would outweight the advantage of not having to type 'pkg install hikari'. similarly for RIP/RIPng, if routed were currently in ports and not in base, there would be very little justification for integrating it into base when someone can just install it from the port. this was different back in the days when routed was first created, because there was no ports system and RIP was common enough that it was useful to users -- along with the fact that 4BSD was effectively the reference implementation of IP and sockets, so shipping RIP was reasonable in that context. so the question for me is not whether it should be in base at all (it clearly shouldn't be, by today's standards), but does the inconvenience to users of removing it outweigh the cost of maintaining the code forever? i don't claim to have any particular expertise here, so people might reasonably disagree, but in my opinion, given the small number of users, the advanced notice period (15.0-RELEASE) and the ease of addressing the problem (pkg install freebsd-routed) the answer is yes. someone elsethread mentioned that they expect FreeBSD to be a "complete operating system". what does this mean in practice? many people expect a complete operating system to include a GUI, yet FreeBSD hasn't shipped X in the base system for quite a while. should we put X back into base? the most sensible way to address this, to me, seems to be that the base OS should include things which are a) widely used, b) not available elsewhere, and c) worth the maintenance cost. for example, the kernel is in base, because there's no FreeBSD without the kernel. /bin/sh is in base because the OS would be unusable without it, even though you can install other shells from ports. /etc/rc is in base because an rc-system is required and /etc/rc is the only one that exists for FreeBSD. fetch(1) is in base even though you can install equivalent software (e.g., cURL) from ports, so you could make an argument that it should be moved to ports. however, fetch is useful for both bsdinstall and for many custom post-installation tasks that need an HTTP client, and attempting to remove it would be very disruptive. cron(8) is in base even though there are other cron implementations, because widely-used parts of the the base system (e.g., periodic(8)) depend on cron for basic functionality; removing cron would also require removing this functionality, and that would be a significant loss to users with no obvious replacement. but routed is not widely used in general, either by users or by the OS itself; there are many implementations of RIP available elsewhere; and the code is both old, barely maintained, and a network server, making it a potential security risk among other maintenance costs. i think a good example here, similar to
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: *owner-freebsd-...@freebsd.org on behalf of Marek Zarychta *Date: *Wednesday, May 15, 2024 at 11:19 AM *To: *freebsd-net@freebsd.org *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 mailto:j...@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 mailto:to...@cedro.info>> wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott mailto: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 FreeBS
Re: removing RIP/RIPng (routed/route6d)
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: owner-freebsd-...@freebsd.org on behalf of Marek Zarychta Date: Wednesday, May 15, 2024 at 11:19 AM To: freebsd-net@freebsd.org 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 mailto:j...@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 > mailto:to...@cedro.info>> wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott > mailto: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. >
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 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. >
Re: removing RIP/RIPng (routed/route6d)
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 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. > > > >
Re: removing RIP/RIPng (routed/route6d)
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. >
Re: removing RIP/RIPng (routed/route6d)
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.
Re: removing RIP/RIPng (routed/route6d)
On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote: > [note: this is a copy of a mail i sent this to arch@, but someone > suggested also asking net@ about this.] > > hello, > > currently FreeBSD ships routed(8) and route6d(8) which implement the RIP > resp. RIPng routing protocols. > > many years ago, it was fairly common for hosts to run these protocols to > get their routing table and it made sense to ship an implementation with > the operating systems. > > nowadays, these are fairly niche protocols and have been replaced in > most networks by either static routing tables (mostly just a default > route) or more modern routing protocols like IBGP/EBGP, OSPF or IS-IS. > as such, i'm not convinced there's any value continuing to ship these > with the OS. > > for people who do want to continue running RIP/RIPng, there are several > implementations available in ports, such as net/bird2 and net/quagga. > > 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. > > does anyone have an opinion on this? Hi, 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? Scott
Re: removing RIP/RIPng (routed/route6d)
On Mon, 15 Apr 2024 at 16:49, Lexi Winter wrote: > > currently FreeBSD ships routed(8) and route6d(8) which implement the RIP > resp. RIPng routing protocols. > ... > 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 agree that retiring these makes sense, and I've added a note about the proposed removal to https://wiki.freebsd.org/DeprecationPlan. Once there's consensus we should add deprecation notices to the man pages and MFC those to stable/14 and stable/13.
removing RIP/RIPng (routed/route6d)
[note: this is a copy of a mail i sent this to arch@, but someone suggested also asking net@ about this.] hello, currently FreeBSD ships routed(8) and route6d(8) which implement the RIP resp. RIPng routing protocols. many years ago, it was fairly common for hosts to run these protocols to get their routing table and it made sense to ship an implementation with the operating systems. nowadays, these are fairly niche protocols and have been replaced in most networks by either static routing tables (mostly just a default route) or more modern routing protocols like IBGP/EBGP, OSPF or IS-IS. as such, i'm not convinced there's any value continuing to ship these with the OS. for people who do want to continue running RIP/RIPng, there are several implementations available in ports, such as net/bird2 and net/quagga. 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. does anyone have an opinion on this? signature.asc Description: PGP signature
