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

61–70 of 119 posts

Re: FTP Must Die

#61

Post by reitzensteinm »

sjwright wrote: post #57
toyg wrote: post #35

Earlier quoted context omitted.

That's actually the standard European order. Testing the Russian locale might be a scary proposition, but certainly not for this specific reason.

It's not just the standard European order, it's the standard order for nearly everywhere on the planet except: > MDY: Belize, USA, parts of Canada, Philippines, Saudi Arabia > YMD: Japan, China, Iran, small bits of Europe > DMY: Probably 3/4 of the planet's land surface That said, YMD should make the most sense (and is most consistent with the universally accepted HMS time format). I try to use YMD wherever I can.

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 this month' (or the 4th of next month, if applicable).

This is the reverse of HMS, where the most significant number (the hour) is most important, and seconds are basically ignored day to day.

MDY, on the other hand, should be taken out the back and shot (IMO).

Re: FTP Must Die

#62

Post by wvenable »

reitzensteinm wrote: post #61
sjwright wrote: post #57

Earlier quoted context omitted.

It's not just the standard European order, it's the standard order for nearly everywhere on the planet except: > MDY: Belize, USA, parts of Canada, Philippines, Saudi Arabia > YMD: Japan, China, Iran, small bits of Europe > DMY: Probably 3/4 of the planet's land surface That said, YMD should make the most sense (and is most consistent with the universally accepted HMS time format). I try to use YMD wherever I can.

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…

> the information is ordered from most to least important for every day access

I argue that MDY is ordered from most to least important for every day access. Year is easily implied so it is last so that leaves month first and then day. You'd be surprised how many Canadians, which is officially DMY, actually prefer MDY.

Re: FTP Must Die

#63

Post by stock_toaster »

toyg wrote: post #40

So, 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, excep…

Webdav maybe?

Many recent OSes support it in some fashion natively, there is a cli client (cadaver), and it runs fine over ssl.

It is rather heavyweight and slow though, and doesn't offer quite the range of things as some ftp servers (ratios, etc). That is likely just due to the lack of popularity and the few options for servers.

SFTP (which you discounted) is probably a better option in many cases though.

Re: FTP Must Die

#64

Post by eslaught »

reitzensteinm wrote: post #61
sjwright wrote: post #57

Earlier quoted context omitted.

It's not just the standard European order, it's the standard order for nearly everywhere on the planet except: > MDY: Belize, USA, parts of Canada, Philippines, Saudi Arabia > YMD: Japan, China, Iran, small bits of Europe > DMY: Probably 3/4 of the planet's land surface That said, YMD should make the most sense (and is most consistent with the universally accepted HMS time format). I try to use YMD wherever I can.

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…

In my opinion YMD is the most useful because it is the most visually distinct from the other two. A date like January 2nd 2012, when arranged in either MDY or DMY format, is difficult to distinguish from February 1st. YMD on the other hand is obvious, independent of what the reader is used to.

Re: FTP Must Die

#65

Post by yuhong »

tptacek wrote: post #42
justincormack wrote: post #32

Earlier quoted context omitted.

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Has there been a piece of equipment shipped in the last 10 years that legitimately couldn't get a TCP running to bootstrap itself? That's why TFTP exists: to avoid the need for TCP.

Well, remember that until recently, BIOSes ran in real mode with it's memory constraints (remember the 640k limit?).

Re: FTP Must Die

#66

Post by kree10 »

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).

Re: FTP Must Die

#67

Post by stock_toaster »

ecaron wrote: post #15
wollw wrote: post #10

Earlier quoted context omitted.

Have you tried using SCP? I don't know if Windows comes with a client but a quick search turned up a few options. It is my goto method for transferring files these days but I admittedly don't use Windows.

I'd love to know the transfer speed differences between SCP, SFTP and FTP - because when I can view both ends of the wire then security is less of a concern than transfer time.

you can use hpn-ssh (high performance) with aes128 (if your hardware has AESNI/padlock/etc) or rc4 (probably faster if your hardware lacks AESNI/padlock/etc) to eke a bit more speed over local connections on trusted lines. throw in compression and you can get good speeds.

rsync-to-rsyncd over a local link is probably faster though (requires more setup though).

You could probably just pipe tarballs through nc too. ;)

Re: FTP Must Die

#68

Post by kree10 »

toyg wrote: post #52
soult wrote: post #45

Earlier quoted context omitted.

I don't see why you disqualify SSH here. If you want a system that only deals with filesystem operations, I suggest NFS. It is neither firewall-, NAT-, proxy- or browser-friendly, is not cross-platform (Windows support only if you pay extra) and is neither encrypted nor authenticated. But hey, it deals with filesystem operations only. If, on the other hand, you want a system that meets your last 3 requirements, just…

SSH is a pain to secure properly, and the potential for mischief is huge. There is no sudo in FTP.

Not that I'd like to encourage it, but there could be a sudo in FTP, along the lines of WU-FTPd's infamous support for a "SITE EXEC" command.

Re: FTP Must Die

#69

Post by LeafStorm »

toyg wrote: post #40

So, 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, excep…

I entertained the idea once of a file-manipulation protocol based on the Redis protocol (with possibly a bit of JSON mixed in for sending structured data like directory listings). The only downside is that the only way I know of to secure it is SSH tunneling...someone should come up with a way to do Redis over TLS.

Re: FTP Must Die

#70

Post by joeyh »

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.
Post reply on HN