Re: git: 24e1824e4646 - main - Deprecate telnet daemon

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Wed, 21 Sep 2022 22:05:38 UTC
In message <20220921215747.bpb2irggvq5bibog@mutt-hbsd>, Shawn Webb writes:
> 
>
> --ws67fbj6tkc5bzg3
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Sep 21, 2022 at 02:55:36PM -0700, Cy Schubert wrote:
> > In message <20220921214546.426y6o4jpnsfsa2l@mutt-hbsd>, Shawn Webb writes:
> > >=20
> > >
> > > On Wed, Sep 21, 2022 at 02:11:44PM -0700, Gleb Smirnoff wrote:
> > > >   Mike,
> > > >=3D20
> > > > On Wed, Sep 21, 2022 at 01:02:17PM -0500, Mike Karels wrote:
> > > > M> I have no problem with deprecating (or removing) telnetd in base. =
>  I
> > > > M> think the client should remain, though.  I use it frequently, alth=
> ough
> > > > M> not on the telnet port.  ftp* are another issue; anonymous FTP is a
> > > > M> perfectly reasonable usage.  I use it to download FreeBSD images o=
> ften.
> > > >=3D20
> > > > Is there any service where telnet to a port would be preferred over n=
> c(1)?
> > >
> > > I wonder if it would be worthwhile to hardlink telnet(1) to nc(1).
> >=20
> > No. Though nc -t is supposed to be compatible with telnet, it is not. No=
> =20
> > sense fooling people into thinking nc, even with the -t argument, is the=
> =20
> > same as telnet. It is not and it will be the source of many PRs which wil=
> l=20
> > eventually waste developer's time making nc behave just like telnet does.=
> =20
> > It is better to simply move it to ports for those who absolutely need it.
>
> Good points. Thanks for the info!

Though discouraged, people can still create a telnet shell alias. But that 
should be left to the individual, not some automatic thing. When adding 
aliases or creating their own symlinks, people typically have a better idea 
of what they're doing. Even if they have no clue and still self-create an 
alias or symlink, should they open a PR the correct answer is don't do what 
hurts you.

Proactively reducing the possibility of tickets in the corporate world 
saves money. In the Open Source world it saves limited and valuable 
developer time which could be better spent on actual productive work.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0