Live data from Hacker News

Transfer.sh – File sharing from the command line

transfer.sh

41–50 of 117 posts

Re: Transfer.sh – File sharing from the command line

#41
post #23

Earlier quoted context omitted.

Static binaries are magic :)

Could you please go into details like what's basic difference b/w static binaries and apps which use dynamic linking. What are the benefits of one over another? Something like grokking this concept for once and all :D

For illustrative purposes, you could think of a static binary kind of like a Docker container. Like a container, within the binary is all of its dependencies, meaning that you are free to install conflicting libraries on the system.

If you use dynamically linked binaries, you rely on the system to have the version of the library you need, and hope that your reliance on those libraries does not break other applications which may rely on different versions of those libs.

Static == everything you need bundled up Dynamic == relies on libraries present on the host to provide aspects of functionality

Re: Transfer.sh – File sharing from the command line

#42

Earlier quoted context omitted.

I love magic wormhole, you give the recipient three words and a number and the file is sent peer-to-peer. No messing about with routing or anything.

How is it for getting around weird networks (double NAT, etc)?

It's been great every time I've used it, I think it has a relay server as a last resort if it can't get a p2p connection. Never had problems with it.

Re: Transfer.sh – File sharing from the command line

#43
post #23

Earlier quoted context omitted.

Static binaries are magic :)

Could you please go into details like what's basic difference b/w static binaries and apps which use dynamic linking. What are the benefits of one over another? Something like grokking this concept for once and all :D

Simplest explanation I can think of: Static binaries have no dependencies. They should just run and not bark about missing (shared/dynamic) libraries, nor require you to install them.

Of course, even static binaries rely on some basic level of compatibility; typically system-level things that don't change much.

Dynamically-linked binaries have the potential to create a massive dependency graph that can hard or even impossible (for a given o/s installation) to traverse.

Re: Transfer.sh – File sharing from the command line

#44
post #4

Earlier quoted context omitted.

I would be much more concerned about people using this site for the transfer of illegal material (such as child abuse imagery). That's something literally any file sharing/image hosting site has to deal with. The 14 day limit won't make a difference as people disseminating that type of material are likely used to having to move it around frequently.

I built a proof of concept project that was a lot like transfer.sh at one point in time. My solution was to not only have a time limit but a download limit as well. I'd guess most people transferring files from the command line want to transfer something from one machine to another, or maybe to a few other machines. I was going to allow a transfer limit of 10 transfers before the file/link went dead, which would hope…

Unless you are storing hashes, what would prevent someone from writing a script that simply reuploads the file to your service after downloading? That would increase the share limit.

Re: Transfer.sh – File sharing from the command line

#45
post #43

Earlier quoted context omitted.

Could you please go into details like what's basic difference b/w static binaries and apps which use dynamic linking. What are the benefits of one over another? Something like grokking this concept for once and all :D

Simplest explanation I can think of: Static binaries have no dependencies. They should just run and not bark about missing (shared/dynamic) libraries, nor require you to install them. Of course, even static binaries rely on some basic level of compatibility; typically system-level things that don't change much. Dynamically-linked binaries have the potential to create a massive dependency graph that can hard or even i…

Those annoying dependency graphs provide both standardized visibility and also the ability to fix and patch components independently of each other.

Re: Transfer.sh – File sharing from the command line

#46
post #15

woof -i -p woof: http://www.home.unix-ag.org/simon/woof.html 1. Allows directory upload/download (tar/gzip/bzip2 compressed) 2. Local file server (doesn't go over the internet) 3. Allows upload form (-U option) 4. Allows file to be served number of times (-c option)

Another alternative for simply serving your current directory which you probably already have:

    python3 -m http.server
or

    python2 -m SimpleHTTPServer

Re: Transfer.sh – File sharing from the command line

#48
post #40

I like it! But for me ssh already provides a simple and secure way to move files from one place or another.. tar -cf - ./files.txt ./orDir/ | ssh host "(cd /dest/dir; tar -xf -)" Given that ssh it so ubiquitous I think this will always be my go to.

What about good old scp?

    scp file.txt user@host:/dest/dir/

Re: Transfer.sh – File sharing from the command line

#49
post #40

I like it! But for me ssh already provides a simple and secure way to move files from one place or another.. tar -cf - ./files.txt ./orDir/ | ssh host "(cd /dest/dir; tar -xf -)" Given that ssh it so ubiquitous I think this will always be my go to.

What about good old scp? scp file.txt user@host:/dest/dir/

Or rsync?

rsync -zvh file.txt user@host:/dest/dir/

So many ways to do this :)

Re: Transfer.sh – File sharing from the command line

#50
post #40

I like it! But for me ssh already provides a simple and secure way to move files from one place or another.. tar -cf - ./files.txt ./orDir/ | ssh host "(cd /dest/dir; tar -xf -)" Given that ssh it so ubiquitous I think this will always be my go to.

If you can trust to have gnu tar on both side, you can reduce typing. I usually do: tar c files.txt orDir | ssh -C host tar x -C /dest/dir
Post reply on HN