Anyone remember Hotline? That was a great protocol/client/server for file transfers.
FTP Must Die
111–119 of 119 posts
Re: FTP Must Die
#112Earlier quoted context omitted.
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.
Programmatic access is essential in such an environment.
Here's a realistic scenario just to make it clearer. An email appending company lands a big client. The client wants to obtain its customers' email addresses on an ongoing basis. They'll send customer information to the email append company who will then send them back the appended files.
Manually moving files is not an option on either side. What method other than FTP do you suggest here?
Re: FTP Must Die
#113Earlier quoted context omitted.
-_- 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.
Programmatic access is essential in such an environment. Here's a realistic scenario just to make it clearer. An email appending company lands a big client. The client wants to obtain its customers' email addresses on an ongoing basis. They'll send customer information to the email append company who will then send them back the appended files. Manually moving files is not an option on either side. What method other…
Most programming environments have SSH/SCP libraries. If you want to maintain a simple upload/download model, SCP is the way to do it.
It's not entirely clear to me that an FTP-style upload/download model is best here, mainly because I haven't the faintest clue what an "email appending company" does.
Re: FTP Must Die
#114FTP is like religion: poorly designed at inception, implemented a thousand different ways and accepted as normal only because it's ubiquitous.
The people who designed FTP were not stupid: they did the best they could operating under constraints that kids who have grown up with all the serious work of implementing the Internet already done for them cannot imagine. It's easy, with decades of hindsight, to claim you could do better. I bet you couldn't.
Re: FTP Must Die
#115Earlier 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…
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.
MDY is syntactically correct English: January 30th, 2012. Or in older form (where it would have come from): "Dated: January the 30th, in the year of our Lord 2012." Even the US Constitution is dated this way. I strongly prefer this way because it makes the most sense in the English language.
For programmatic sorting YMD makes sense because is automatically sorts by Y, M, D, if compared as a string. (EG: on a filesystem.)
Re: FTP Must Die
#116Earlier quoted context omitted.
No, in fact I update every 6 months ever since I started using OpenBSD back in 1999. The problem isn't setting up OpenSSH to offer chrooted sftp access. My gripe is that the sftp subsystem for no solid reason requires that a user directory is root-owned in order to chroot even when the user account experiences a forced sftp response (that is, denying shell access, making it an sftp-only account).
the reason the directory must be root owned, is that the chroot directive is also used for normal ssh sessions, where a user owned chroot directory can mean that a user can break out.
Yeah I'm aware of that part. I submitted a number of design suggestions, as well as a patch, to the OBSD devs which disregarded the root ownership check if the SFTP subsystem was called by a connecting client, but no one bothered even discussing the topic. The whole /home/user/user/ directory nesting just rubs me the wrong way.
Re: FTP Must Die
#117FTP 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…
One important firewall that can't deal with it: Amazon's NAT images for EC2. AFAICT, there's no way to run an ftp client behind Amazon's NAT unless you open all outbound ports, because the server is still the one that specifies which port the client should use for its PASV connection.
I think most firewalls solve this by actually rewriting the FTP packets on the fly (IIRC Cisco calls these "fixups"). That's seriously, seriously broken.
Re: FTP Must Die
#118Earlier quoted context omitted.
-_- 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.
Programmatic access is essential in such an environment. Here's a realistic scenario just to make it clearer. An email appending company lands a big client. The client wants to obtain its customers' email addresses on an ongoing basis. They'll send customer information to the email append company who will then send them back the appended files. Manually moving files is not an option on either side. What method other…
OK then, while I don't have much experience with Java and C#, 15 seconds of googling showed me at least one broadly used and well supported, open source library for SSH/SCP for each of these languages. Undoubtedly, there are others that are not free but backed by a real company. This is aside from 'integrating' SCP in the way people 'integrate' FTP - by calling the command line version.
So, whether we define 'platform' as 'OS' or 'programming language', my point stands: name me one (actually used, not VMS) platform for which there is no SCP available.
Re: FTP Must Die
#119Earlier quoted context omitted.
Programmatic access is essential in such an environment. Here's a realistic scenario just to make it clearer. An email appending company lands a big client. The client wants to obtain its customers' email addresses on an ongoing basis. They'll send customer information to the email append company who will then send them back the appended files. Manually moving files is not an option on either side. What method other…
OK then, while I don't have much experience with Java and C#, 15 seconds of googling showed me at least one broadly used and well supported, open source library for SSH/SCP for each of these languages. Undoubtedly, there are others that are not free but backed by a real company. This is aside from 'integrating' SCP in the way people 'integrate' FTP - by calling the command line version. So, whether we define 'platfor…
The availability of SCP is irrelevant. What matters is support. I'm glad you did your research but you came to the wrong conclusion; the conclusion you should have come to is that FTP is much more tightly integrated. In C# it's part of the standard library; in Java it's an Apache library everyone has.
I think you're overvaluing what is the "best" method of file transfer. When you have to set up a file transfer process with a client, and tens or hundreds of thousands of dollars are on the line, you are going to choose the path of least resistance. That path is FTP. Clearly. If you are the much bigger company you have a better chance of doing things the "right way" but that rarely happens just because these are ultimately business decisions and business doesn't care about implementation details unless they cost money.