there are fusefs under linux if you like do a persistent link
On mer., 2026-07-08 at 07:24 +0200, jean-christophe wrote:
> scp for transfer or rsync may be...
>
> On mer., 2026-07-08 at 00:24 +0000, Andy Smith wrote:
> > Hello,
> >
> > On Wed, Jul 08, 2026 at 12:36:36AM +0200, Christian Groessler
> > wrote:
> > > In "trusted local networks" one could use telnet and forget about
> > > ssh
> > > overhead...
> >
> > I don't really follow the logic. telnet is not designed for file
> > transfer but for interactive login. The trivial overhead of
> > encryption
> > and initial key exchange won't be at all noticeable in an
> > interactive
> > terminal session so why would you ever use antiquated and
> > poorly-maintained software like telnet? ssh is right there and
> > works
> > fine.
> >
> > Even when it comes to bulk data transfer, SSH is not really slowed
> > down
> > that much by encryption and key exchange. I have no problem doing
> > 500MB/s from an nvme, through SSH over the local network to another
> > nvme. The bottleneck isn't the CPU unless we are talking very weak
> > systems. The bottleneck is down to the fact that SSH isn't a
> > dedicated
> > file transfer tool and just uses a single TCP stream with
> > conservative
> > window scaling. This still works quite well on reliable, low
> > latency
> > links. TCP really falls apart on high latency links with even a
> > tiny
> > amount of loss, but local networks aren't usually like that.
> >
> > But even if you DID find encryption overhead to be an issue, you
> > wouldn't try to shove massive amounts of data though telnet, you
> > would
> > just us something like nc! It's packaged in Debian and installing
> > it
> > on
> > both ends is far more sane than running telnetd on one end and
> > telnet
> > client on the other!
> >
> > There is almost no scenario in which running telnetd makes sense,
> > even
> > on an isolated network where every host is on your desk, except
> > perhaps
> > nostalgia.
> >
> > Thanks,
> > Andy
