> On 03/04/2021 22:39, Ed Maste wrote: > > I propose deprecating the ftpd currently included in the base system > > before FreeBSD 14, and opened review D26447 > > (https://reviews.freebsd.org/D26447) to add a notice to the man page. > > I had originally planned to try to do this before 13.0, but it dropped > > off my list. FTP is not nearly as relevant now as it once was, and it > > had a security vulnerability that secteam had to address. > > > > I'm happy to make a port for it if anyone needs it. Comments?+1 for port. I suspect I last used an FTPd in anger sometime in late 90s, and I surmise this is the vast majority. We will have a very small # of users who require FTPd at all, to make their systems useful. An even smaller # of those users will be unable to use FreeBSD if FTPd is only available in a pkg. For those objecting, are you *really* in that latter category -- are these boxes running without a single port/package installed? When 13.0 goes EOL, somewhere after 2025, will you *still* need ftpd in 14.0 base? It seems a reasonable delay, even for a large corporate, to accommodate this change, which can be done in less time than reading this email. Ian's point about preserving paths is a reasonable one, but I had to add an ntpd user in last updates, this would be less difficult. Eugene mentioned the convenience of ftpd in the same sentence as ipsec. I'm willing to bet those systems have ports installed too. If speed is an issue, HTTP supports pipelining, compression, chunked encoding, & parallel connections. I'm not sure ftpd is even in the same game anymore. The more code we hang onto in base, the larger the millstone around our necks when moving forwards. Each individual opportunity to slim down base *in itself* is not significant, but cumulatively they represent gridlock. For each removal or deprecation, please consider, is this worth holding the project back for? # /etc/src.conf WITHOUT_CRUFT=yes A+ Dave
Dave Cottlehuber wrote:>> On 03/04/2021 22:39, Ed Maste wrote: >> > I propose deprecating the ftpd currently included in the base system >> > before FreeBSD 14, and opened review D26447 >> > (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> > I had originally planned to try to do this before 13.0, but it dropped >> > off my list. FTP is not nearly as relevant now as it once was, and it >> > had a security vulnerability that secteam had to address. >> > >> > I'm happy to make a port for it if anyone needs it. Comments? > >+1 for port. I suspect I last used an FTPd in anger sometime in late 90s, >and I surmise this is the vast majority. > >We will have a very small # of users who require FTPd at all, to make their >systems useful.And I bet there are not a lot of users that need caesar, fortune, ... to make their system useful either. If the goal is to strip the system down, there are lots of stuff not needed in /usr/src.>An even smaller # of those users will be unable to use FreeBSD if FTPd is >only available in a pkg.Yep. But it's a bit of a bother, although I can definitely live with one in ports.>For those objecting, are you *really* in that latter category -- are >these boxes running without a single port/package installed?At the moment I have one called "git", plus the dozens of things it pulls in.>When 13.0 goes EOL, somewhere after 2025, will you *still* need ftpd in >14.0 base? It seems a reasonable delay, even for a large corporate, to >accommodate this change, which can be done in less time than reading >this email.No more or less convenient than now.>Ian's point about preserving paths is a reasonable one, but I had to add >an ntpd user in last updates, this would be less difficult. > >Eugene mentioned the convenience of ftpd in the same sentence as ipsec. >I'm willing to bet those systems have ports installed too. > >If speed is an issue, HTTP supports pipelining, compression, chunked >encoding, & parallel connections. I'm not sure ftpd is even in the same >game anymore.Nope, just easy to move small files around the machines in front of me. I have no interest in setting up a web server. I wonder what others find convenient when moving files to/from Windows?>The more code we hang onto in base, the larger the millstone around our >necks when moving forwards. Each individual opportunity to slim down >base *in itself* is not significant, but cumulatively they represent >gridlock.Maybe they should take "ls /usr/bin", remove the obvious essential ones and have a survey to determine what else is widely used/needed?>For each removal or deprecation, please consider, is this worth holding >the project back for? > ># /etc/src.conf >WITHOUT_CRUFT=yesrick A+ Dave _______________________________________________ freebsd-stable at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
On 05.04.2021 06:25, Dave Cottlehuber wrote:> Eugene mentioned the convenience of ftpd in the same sentence as ipsec. > I'm willing to bet those systems have ports installed too.Ports/packages are great but they are not replacement for solid operating system with bundled software tested and proven with time.> If speed is an issue, HTTP supports pipelining, compression, chunked > encoding, & parallel connections. I'm not sure ftpd is even in the same > game anymore.Compression and various encodings of raw data are not good for speed. sendfile(2) system call used by ftpd to send raw data is good for speed. Unlimited CPU power should not be assumed.> The more code we hang onto in base, the larger the millstone around our > necks when moving forwards. Each individual opportunity to slim down > base *in itself* is not significant, but cumulatively they represent > gridlock. > > For each removal or deprecation, please consider, is this worth holding > the project back for?Our ftpd code does not hold the project back in any way. It's here, it works, it's very good. High quality bundled software is what we love FreeBSD for. Unfortunately, ports tend to rot more quick due to some known reasons.