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 routed, would be window(1).  30
> years ago, i used window(1) all the time; it was very useful and an
> obvious candidate for a base utility considering how (relatively) common
> text terminals were.  but since then, the world changed: text consoles
> are less common (in favour of GUIs) and people nowadays are more likely
> to use screen(1) or tmux(1), modern utilities which do the same thing
> better.  so while window(1) had enough remaining users to justify moving
> it to a port, it failed to meet the requirements a) and c) above.
> 
> 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.)
> 
> ---
> 
> a couple of people also mentioned pkgbase and i think this is likely to
> have an effect on this sort of discussion, especially because it makes
> the current hard divide between src and ports more permeable: there's
> not much difference between typing 'pkg install FreeBSD-routed'
> (pkgbase) or 'pkg install freebsd-routed' (ports), for example.
> 
> i like pkgbase and use it on all my systems, so i'm very interested to
> see where this leads.  in fact, i originally intended to submit a patch
> to move routed into a new pkgbase package, as i've recently done with
> some other base utilities.  in the ended i decided, based on the
> reasoning above, that it made more sense to simply remove it.
> 
> my guess is that if/when pkgbase does become the default, it will make
> it easier to justify removals like these, because if you already have to
> install routed (or whatever) from a pkgbase package, it's not much of a
> change to install it from a ports package instead.

Thanks Lexi,

most of my concerns are addressed, especially that of routed/route6d being 
moved into ports.  If you'd known of this when you wrote your first post and 
communicated it I may be been less likely to respond.  That said if the 
purpose of socialising the idea of removal was to solicit constructive 
feedback I'd have responded regardless, if only to champion routed as a 
useful (and still used) piece of software.

I'm never sure whether to respond to sophistry and rhetoric, but why not, 
let's play:

> 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?

Maybe, but I'm the wrong person to ask.  The answer depends on the criteria 
for the novel or continued inclusion of any FreeBSD feature.  And I have no 
idea what such criteria are.

> so the question for me is not whether it should be in base at all

Well, it was originally.

> (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?

Again, I've no idea what "today's standards" are, and so the "clearly" 
modifier is lost on me.  If I were aware of these standards I'd be open to 
agreeing, however.  The "forever" adverb is addressing a assertion waiting to 
be claimed and I don't think anyone has done so yet.  It doesn't take a lot 
of imagination to see a time when it should be unarguably removed.

> 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?

What's going on here?  We're not talking about X.  We are having this 
conversation in the absence of clear criteria about the specific question of 
how a distinct function that FreeBSD currently ships qualifies for removal.  
Your OP merely suggested that you saw no value in routed's continued 
existence in base and what I thought was an entreaty for alternate views.

> 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 better question is "should"?  If we knew the rules the answer would be 
obvious.

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.

As I stated earlier - my main concern was a loss in functionality, and should 
routed/route6d be moved to ports (and maintained) then this is a non-issue 
(for me).  It could be argued that FreeBSD must contain at least "bootstrap" 
functionality and that routed qualifies as such, although I'm not sure I 
could build a great case here.

Regards,
Scott