Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My contribution to XKCD’s #949

joachim-breitner.de

Post reply on HN
Print view View original

51–56 of 56 posts

Re: My contribution to XKCD’s #949

#51

Post by nomeata »

laumars wrote: post #44
nomeata wrote: post #39

Earlier quoted context omitted.

Because with file-share, the file is never stored on the ssh-server; it is transferred the instant the other sides starts the download. The SSH-Server is required to share the file at a publicly available address (which my own computer is likely not). So no need to clean up files after the download, for example, or even to have any free disk space.

If you need an SSH server to begin with, then there's still some setting up you need to do before hand. The pain of having to delete a few files afterwards is really nothing compared to renting a Linux box, setting up SSH accounts with fail2ban and/or SSH keys; and so on. So file-share doesn't even work as a pain free solution like you suggest it does. As I said before, I don't like to stamp on another's creativity.…

Why would you have to mess with SSH account_s_? Only the sending side needs an account, no further setup on the server required. It doesn’t even have to be your server, your university’s server is enough.

Re: My contribution to XKCD’s #949

#52

Post by nomeata »

brechin wrote: post #49

I've got a CLI that lets you upload a file through FileTea. I'll clean up the source and post it soon. See https://github.com/brechin/FileTeaSend Tested with Python 2.6. Only external requirement is requests.

Great! Guess I’ll ditch my tool sooner than I thought...

Re: My contribution to XKCD’s #949

#54

Post by brechin »

nomeata wrote: post #52
brechin wrote: post #49

I've got a CLI that lets you upload a file through FileTea. I'll clean up the source and post it soon. See https://github.com/brechin/FileTeaSend Tested with Python 2.6. Only external requirement is requests.

Great! Guess I’ll ditch my tool sooner than I thought...

Glad I could help!

Re: My contribution to XKCD’s #949

#55

Post by laumars »

nomeata wrote: post #51
laumars wrote: post #44

Earlier quoted context omitted.

If you need an SSH server to begin with, then there's still some setting up you need to do before hand. The pain of having to delete a few files afterwards is really nothing compared to renting a Linux box, setting up SSH accounts with fail2ban and/or SSH keys; and so on. So file-share doesn't even work as a pain free solution like you suggest it does. As I said before, I don't like to stamp on another's creativity.…

Why would you have to mess with SSH account_s_? Only the sending side needs an account, no further setup on the server required. It doesn’t even have to be your server, your university’s server is enough.

Most people are not at uni and rented boxes usually have root open by default expecting customers to then disable root access and create a user with su / sudo rights. Plus I tend to take things further and create a dedicated groups for ssh so that rsync / sftp users cannot use a system shell nor port forward and are chrooted while a very small subset of administrators have full ssh access.

Plus even if you do borrow someone else's box, can you be sure that they'd even be grateful that you're using up their bandwidth?

Ssh is a dangerous protocol to leave open to the WAN, so setting up an ssh server properly, while not a time consuming job, will still take longer and more effort than simply deleting a few files afterwards.

Re: My contribution to XKCD’s #949

#56

Post by verroq »

tOkeshu wrote: post #42
verroq wrote: post #7

You can always uses a p2p data transfer with WebRTC. All you need is a browser.

It is way more complicated than that. WebRTC is all great and shiny but there is strong obstacles to build correct data transfer applications on top of that: - You still need a server to do the "signaling" part - NAT are everywhere and will fail your p2p connections sometimes (14% of WebRTC calls according to Google, back in may) [1] - Ultimately there is a problem with JavaScript API that does not allow you to downl…

Having used webRTC with the TURN server REST API (multimedia conferencing app), it's not that bad.

STUN will get though the NAT most of the times. With the latest browsers, Firefox to Chromium is a bit dodgy, but there are workarounds. But Chromium to Chromium is perfectly fine.

Post reply on HN