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

FTP Must Die

mywiki.wooledge.org

Post reply on HN
Print view View original

101–110 of 119 posts

Re: FTP Must Die

#101

Post by plq »

kree10 wrote: post #66
sehugg wrote: post #17

I don't think FTP must die so much as RSYNC MUST LIVE. (Seriously, people forget how awesome rsync is. And it tunnels/compresses nicely over SSH)

Also don't forget that rsync does not overwrite a remote file until it's completely uploaded. Compare to ftp, sftp and scp, which overwrite the file from the start, possibly breaking your site during the transfer (or definitely breaking your site if the transfer dies part-way through).

> Also don't forget that rsync does not overwrite a remote file until it's completely uploaded.

which is really troublesome when you're transferring a big file and the target doesn't have enough space for a second copy of that particular file. I, for one, would prefer that "feature" to be optional.

Re: FTP Must Die

#102

Post by rplnt »

sjwright wrote: post #55
pygorex wrote: post #8

FTP is like religion: poorly designed at inception, implemented a thousand different ways and accepted as normal only because it's ubiquitous.

Except unlike religion, FTP began with a legitimate use-case scenario.

Don't know about all religions but some began with clear use-cases. To retain (or even achieve) power over people. For example The Old Testament was written/compiled for this very reason[1].

1. http://books.google.com/books?id=iS7rQwAACAAJ

Re: FTP Must Die

#103

Post by kree10 »

plq wrote: post #101
kree10 wrote: post #66

Earlier quoted context omitted.

Also don't forget that rsync does not overwrite a remote file until it's completely uploaded. Compare to ftp, sftp and scp, which overwrite the file from the start, possibly breaking your site during the transfer (or definitely breaking your site if the transfer dies part-way through).

> Also don't forget that rsync does not overwrite a remote file until it's completely uploaded. which is really troublesome when you're transferring a big file and the target doesn't have enough space for a second copy of that particular file. I, for one, would prefer that "feature" to be optional.

Take a look at rsync's "--inplace" option. I think this does what you want.

Re: FTP Must Die

#104

Post by moe »

viraptor wrote: post #87
moe wrote: post #24

Sign me up, but where's the alternative? WebDAV is a trainwreck. SFTP could be nice but the OpenSSH impl falls terribly short as a FTPd replacement (the most useful implementation is ironically the one in ProFTPd). Sendfile never went anywhere. Network filesystems don't cut the FTP use-case either. People don't use FTP because they like it. They use it for the lack of a viable alternative.

> the OpenSSH impl falls terribly short as a FTPd replacement any specific reason?

No way to chroot users to their home, generally finicky configuration (way too easy to give users shell-access by accident), no bandwidth throttling or other advanced ftp features, rather limited logging/auditing.

Re: FTP Must Die

#105

Post by bane »

sjwright wrote: post #72
reitzensteinm wrote: post #61

Earlier quoted context omitted.

YMD is logical, because it puts the most significant number on the left. But both DMY and HMS are consistent in another way - the information is ordered from most to least important for every day access, from left to right. A vast majority of dates on advertising, tickets, timetables etc actually leave off the year, unless it's ambiguous. Similarly, one might say something like 'on the 4th', which implies 'the 4th of…

[edited because I realized we're in violent agreement] To me, MDY makes as much sense as writing pi as 14.3.159265

It's probably a legacy from how we tend to say dates.

"What's the date?"

"January 30th."

Re: FTP Must Die

#106

Post by Nelson69 »

pygorex wrote: post #8

FTP is like religion: poorly designed at inception, implemented a thousand different ways and accepted as normal only because it's ubiquitous.

FTP is kind of dying out though.

Now the religion of SMTP.. I often wonder how the spam situation would look if we redid SMTP and required certified TLS. What's worse, we still use SMTP for real stuff every day, I get emails from Etrade, Fidelity and others that I simply don't want flying through cyberspace decrypted even if they don't contain real information.

Re: FTP Must Die

#107

Post by MatthewPhillips »

roel_v wrote: post #95
MatthewPhillips wrote: post #34

Earlier quoted context omitted.

FTP is platform agnostic. As uncool as it may be it's the only realistic choice for companies to share sensitive data.

Please, name me one platform in common use that doesn't have an implementation of ssh/scp.

Java, C# which covers a good 80+ percent of enterprise software. Moving data from one company to another for processing is big, big business. The type of thing not discussed on HN because it's not relevant here, but it must happen for those types of companies and FTP is really the only thing you can ask a paying client to use without asking them to rely on unsupported/abandoned/old third party libraries.

Re: FTP Must Die

#108

Post by toyg »

bane wrote: post #105
sjwright wrote: post #72

Earlier quoted context omitted.

[edited because I realized we're in violent agreement] To me, MDY makes as much sense as writing pi as 14.3.159265

It's probably a legacy from how we tend to say dates. "What's the date?" "January 30th."

That used to be the case in the UK, but I notice more and more how I'm the only one actually using that form in conversation these days, at least in my little corner of Northern England. Indigenous people have clearly moved on to DMY, i.e. "the 30th of January".

Re: FTP Must Die

#109

Post by dspillett »

joeyh wrote: post #70

It's perhaps worth noting that HTTP has essentially the same unspecified directory list problem as FTP. I've seen programs that screen scrape apache etc directory lists (as displayed when there is no index.html). Oddly, gopher was an intermediate protocol that got that right.

HTTP wasn't really intended as a file/directory transfer protocol the same though. The problems with FTP means that is fails at its primary function (unless you apply copious work-arounds).

Many moons ago in my younger days I wrote an FTP based file/tree synchronisation tool. I have since vowed to never touch FTP again.

Re: FTP Must Die

#110

Post by roel_v »

MatthewPhillips wrote: post #107
roel_v wrote: post #95

Earlier quoted context omitted.

Please, name me one platform in common use that doesn't have an implementation of ssh/scp.

Java, C# which covers a good 80+ percent of enterprise software. Moving data from one company to another for processing is big, big business. The type of thing not discussed on HN because it's not relevant here, but it must happen for those types of companies and FTP is really the only thing you can ask a paying client to use without asking them to rely on unsupported/abandoned/old third party libraries.

-_- Java & C# are not platforms, they're programming languages. I'm making an effort here to understand you, but I don't see how a programming language can relate to the availability of file transfer tools.
Post reply on HN