Plan 9's 9P is a nice file protocol: http://plan9.bell-labs.com/sys/man/5/INDEX.html.
A client implementation has been available for Linux since version 2.6 (http://cm.bell-labs.com/wiki/plan9/v9fs/index.html).
FTP Must Die
31–40 of 119 posts
Re: FTP Must Die
#32FTP is definitely outdated, and there are better uses in many circumstances. But I find some of these criticisms a bit odd. The client listening was largely solved by 'passive' mode, and just about every server and client supports this now. The firewall and NAT interaction is awkward, but most modern firewalls can deal with this automatically (as long as there's no SSL involved) And yes, the RFC is 20 years old. But…
PASV mode came with its own security drama, and doesn't address the core issue with the (absolutely pointless) multiple-connection model of FTP. And so, yes, firewalls and NATs "interact" with FTP --- because they all had to be hacked specifically to deal with the FTP protocol, which moots your rebuttal --- but in doing so they create additional security issues, like the NAT pinning stuff Samy Kamkar posted last year…
Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...
Re: FTP Must Die
#33We've got a writeup about how much fun it was implementing a FUSE based filesystem that transports with FTP [ExpanDrive]
http://blog.expandrive.com/2009/02/02/ftp-considered-harmful...
Re: FTP Must Die
#34FTP is definitely outdated, and there are better uses in many circumstances. But I find some of these criticisms a bit odd. The client listening was largely solved by 'passive' mode, and just about every server and client supports this now. The firewall and NAT interaction is awkward, but most modern firewalls can deal with this automatically (as long as there's no SSL involved) And yes, the RFC is 20 years old. But…
FTP is as obsolete as telnet and has no place being alive today. SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.
FTP is platform agnostic. As uncool as it may be it's the only realistic choice for companies to share sensitive data.
Re: FTP Must Die
#35You might be amused to browse Chrome's implementation of FTP, which has separate modules for each of the different types of FTP servers you might encounter, as each emits the "ls -l" output in a different way and that is (I guess) the only way to get file sizes. http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=net/... see all the "directory listing" files. The unit tests are full of scary cases like // Tests f…
That's actually the standard European order. Testing the Russian locale might be a scary proposition, but certainly not for this specific reason.
Re: FTP Must Die
#36Earlier quoted context omitted.
FTP is as obsolete as telnet and has no place being alive today. SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.
FTP is platform agnostic. As uncool as it may be it's the only realistic choice for companies to share sensitive data.
Sensitive data? Over an unsecured protocol?
Re: FTP Must Die
#37Earlier quoted context omitted.
FTP is as obsolete as telnet and has no place being alive today. SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.
How do you mean, SFTP is a hack that suffers from all the same problems? SFTP is a new protocol, it's not the same as FTP. It doesn't concern itself with data port nonsense, and while it doesn't offer authentication or secure transfers in itself, there is - at least to my knowledge - no SFTP solution available that doesn't perform SFTP via an underlying mechanism for secure auth/transfer.
I suspect the GP was referring to FTP over SSL, which is an ugly abomination with few redeeming features.
Re: FTP Must Die
#38Plan 9's 9P is a nice file protocol: http://plan9.bell-labs.com/sys/man/5/INDEX.html . A client implementation has been available for Linux since version 2.6 ( http://cm.bell-labs.com/wiki/plan9/v9fs/index.html ).
Unfortunately 9P2000 tends to perform badly over high latency connections. There was talk of writing a new version that would allow clients to group certain messages, but nothing ever came of it.
Edit: I just found a very recent paper on Improving the performance of Styx based services over high latency links (Styx being the Inferno name for 9P): http://gsyc.es/tr-docs/RoSaC-2011-2.pdf
Re: FTP Must Die
#39Browser HTTP file upload is still terrible for file transfer. One of the last bastions of Flash, regretfully.
Browsers are terrible at file upload. The weakness here isn't really in the protocol.
That's why I said browsers. But only recently with HTML5 XHR file uploads we could have progress and status reported in-page (instead of poorly in the status bar, if any). And it's still not good enough and definitely not widely available.
Re: FTP Must Die
#40So, what would it be a modern drop-in replacement for FTP?
Requirements:
* It should only deal with filesystem operations (i.e. SSH is way too problematic).
* It should be firewall-, NAT-, proxy- and browser-friendly.
* It should have cross-platform servers and clients, fully operational via CLI as well as GUI.
* it should be secure (i.e. no http, thanks; https, maybe.)
I'd say it's potential startup territory, except I cannot see any monetization opportunity. Also, the usual XKCD on standards: http://xkcd.com/927/