Re: local network capability scanner?
On Friday 07 February 2020 14:29:08 David Wright wrote:
> On Fri 07 Feb 2020 at 11:24:46 (-0500), Gene Heskett wrote:
> > On Friday 07 February 2020 10:20:45 David Wright wrote:
> > > On Fri 07 Feb 2020 at 08:12:18 (-0500), Gene Heskett wrote:
> > > > I was trying different ways to move a kernel src to the pi for
> > > > making and also reached the conclusion that mc was for some
> > > > reason terminally slow at unpacking an .xz kernel and writing
> > > > the unpack across the network. It was promising me a 43+ hour
> > > > ETC. And was showing figures when it updated the screen here as
> > > > 4.3
> > > > kilobytes/second? Really?
> > >
> > > Ooh, gosh, don't do that! Even with a cat5 cable between two
> > > machines, ¹unpacking an archive across the link with mc¹ will take
> > > at least 100x more than ²transferring the archive and unpacking at
> > > the destination², even if you do said unpacking with mc.
> >
> > you miss-understood, both the archive and mc were on this machine
> > and only the output of the unpack was going out over the cat5.
>
> Yes, that's what I described in ¹… …¹, and it's slow. AIUI mc sends
> the filename and stat information across the link (so that the other
> end knows where to put it, and what metadata to use), then it sends
> the file (which is usually much larger). When the other end indicates
> that the file arrived, mc starts on the next file.
>
And since the upacked kernel archive has tons of individual functions
which may be only a 2 kilobyte file, the over head on the cat-5 is 20kb
to send a 2kb file. The light finally comes on.
> > > fish is fine for the odd file transfer, and I guess it's faster
> > > than kermit (untested), but there's a large overhead on each file.
> >
> > I don't use fish that I know of. Thats not to say mc isn't using
> > it. In which case someone has been playing with mc that has no clue
> > what they are doing.
Because mc, 22+ years ago was pretty much self-contained. Now, AFAIAC,
mc has been contaminated, albeit invisibly just to keep it working as
ways and means have changed. Not always an improvement but it still
works for some definition of works. In this case, stretching the hell
out of the definition of "works".
>
> If you're not running any suitable server at the other end (are you?),
just an ssh -Y connection, which may at times be supplemented as I also
use an sshfs "mount", which works well as long as its user 1000 on both
ends of the cable. Root access is disallowed going either way as part of
my security model here. I've long since given up on ever keeping an nfs
share work here for more than a month or so, somebody is always screwing
with it breaking established connections. Samba/cifs has been broken at
weekly intervals since Tridgel? took on a partner many yeas ago now.
So I use what works, ssh and friends, which tries by encoding the
transfer to guard against MITM attacks. And is about 10000% more
dependable.
> then instead of the first line of /usr/lib/mc/fish/* telling a fish
> server what to do, the script is handed to bash, which ignores that
> first line (# comment) and executes the shell commands instead.
> Those echo lines in the scripts are what would be the fish server's
> return codes going back to mc.
>
> > > > So I stopped that, killed the partial copy, backed out and
> > > > copied the whole image to the pi in just 2 or 3 minutes, with
> > > > mc, then unxz'd it on the pi in maybe 3 minutes.
>
> Yes, you then used ²… …² above which is fast because mc only has to
> deal with sending a single, smaller (compressed) file.
But its still well over a gigabyte.
>
> > > > So maybe bit rot in mc? DIIK.
> > >
> > > Take a look at the scripts in /usr/lib/mc/fish/ and imagine
> > > running a couple of them on each and every file in the kernel.
Fuggly.
> > According to the README.fish, there, mc does use the scripts in that
> > directory. But fish itself is not installed.
> >
> > Perhaps it should be? And the slowness is because its not? Another
> > DIIK.
>
> I'm not aware that there's a faster way of sending the files once
> you've unpacked the archive locally. After all, you've thrown away the
> benefits of compression and aggregation.
Understood now.
> Cheers,
> David.
Thanks David
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: