31–40 of 56 posts
Didn't Dropbox's share links more or less solve this problem? Maybe not for 100% of the population, but I've managed to walk my mom through the process, and isn't that generally the success metric for things like this?
The usage proposed here is a "no-strings" attached approach. Ideally you want something you can trust, hence free software, and that does not store anything.
The problem isn't 'sending a file', it's 'peer to peer communication', which is hard without an intermediary and/or shennanigans due to ubiquitous NAT. I image in the everyone-has-an-IP universe of ip6, this will no longer be an issue.
ipv6 will still have this issue, because _no fucking way_ will i put a directly-accessible-from-anywhere computer on a network. the "how do i serve a directory" problem is _so_ solved: `python -m SimpleHTTPServer` or: dropbox (it's not hard to install, as much as xkcd whinges about it) google drive email This is a solved problem.
followed by
> python -m SimpleHTTPServer
is a bit of a contradiction.
Dropbox has some pretty serious limitations for transferring files; you're limited on file size, you have to upload to their servers, you're subject to their definition of objectionable content, and sharing a particular file too much (for their definition of too much) will cause them to take down the file.
Earlier quoted context omitted.
ipv6 will still have this issue, because _no fucking way_ will i put a directly-accessible-from-anywhere computer on a network. the "how do i serve a directory" problem is _so_ solved: `python -m SimpleHTTPServer` or: dropbox (it's not hard to install, as much as xkcd whinges about it) google drive email This is a solved problem.
> directly-accessible-from-anywhere computer on a network followed by > python -m SimpleHTTPServer is a bit of a contradiction. Dropbox has some pretty serious limitations for transferring files; you're limited on file size, you have to upload to their servers, you're subject to their definition of objectionable content, and sharing a particular file too much (for their definition of too much) will cause them to take…
>Dropbox has some pretty serious limitations for transferring files; you're limited on file size, you have to upload to their servers, you're subject to their definition of objectionable content, and sharing a particular file too much (for their definition of too much) will cause them to take down the file.
Link to this being a real problem for someone?
Earlier quoted context omitted.
I recently had to sign up with Dropbox just to download a file somebody was sharing with me. The way UbuntuOne (and maybe other providers) just give you a link anybody can use is much better imho.
I'm pretty sure they did it wrong then. You can share a link to any file inside of your dropbox, and anyone can download it regardless of whether they have an account.
I don't mean to stamp on someone's creativity, but SSH already has a whole bunch of tools for transferring files - all of which already work pretty well.
"You can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem." https://news.ycombinator.com/item?id=9224 :)
It's a really geeky approach. The 949 problem concerns a lot of persons who does not even know what a server is.
"You can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem." https://news.ycombinator.com/item?id=9224 :)
So he's built a file sharing tool which requires an SSH server to work? So why not just use sshfs, scp or rsync? I don't mean to stamp on someone's creativity, but SSH already has a whole bunch of tools for transferring files - all of which already work pretty well.
"You can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem." https://news.ycombinator.com/item?id=9224 :)