1 |
Am Sat, 29 Apr 2017 20:02:57 +0100 |
2 |
schrieb lee <lee@××××××××.de>: |
3 |
|
4 |
> Alan McKinnon <alan.mckinnon@×××××.com> writes: |
5 |
> |
6 |
> > On 25/04/2017 16:29, lee wrote: |
7 |
> >> |
8 |
> >> Hi, |
9 |
> >> |
10 |
> >> since the usage of FTP seems to be declining, what is a replacement |
11 |
> >> which is at least as good as FTP? |
12 |
> >> |
13 |
> >> I'm aware that there's webdav, but that's very awkward to use and |
14 |
> >> missing features. |
15 |
> >> |
16 |
> >> |
17 |
> > |
18 |
> > Why not stick with ftp? |
19 |
> |
20 |
> The intended users are incompetent, hence it is too difficult to |
21 |
> use ... |
22 |
|
23 |
If you incompetent users are using Windows: Have you ever tried |
24 |
entering ftp://user@××××××××.tld in the explorer directory input bar? |
25 |
|
26 |
> > Or, put another way, why do you feel you need to use something |
27 |
> > else? |
28 |
> |
29 |
> I don't want to use anything else. |
30 |
> |
31 |
> Yet even Debian has announced that they will shut down their ftp |
32 |
> services in November, one of the reasons being that almost no one uses |
33 |
> them. Of course, their application is different from what I'm looking |
34 |
> for because they only have downloads and no uploads. |
35 |
|
36 |
And that's the exact reason why: Offering FTP just for downloads (not |
37 |
even for browsing) is inefficient. Getting a file via HTTP is much more |
38 |
efficient as the connection overhead is much lower. Removing FTP is |
39 |
thus just a question of reducing attack surface and server load. |
40 |
|
41 |
Your scenario differs a lot and doesn't follow the reasoning debian put |
42 |
behind it. |
43 |
|
44 |
> However, another reason given was that ftp isn't exactly friendly to |
45 |
> firewalls and requires "awkward kludges" when load balancing is used. |
46 |
> That is a pretty good reason. |
47 |
|
48 |
This is due to FTP incorporating transfer of ports and IP addresses in |
49 |
the protocol which was a good design decision when the protocol was |
50 |
specified but isn't nowadays. Embedding FTP into a tunnel solves that, |
51 |
e.g. by using sftp (ssh+ftp). HTTP also solves that by not embedding |
52 |
such information at the protocol level. But tunneling FTP is not how |
53 |
you would deploy such a scenario, so the option is HTTP, hence FTP can |
54 |
be shut down by debian. KISS principle. |
55 |
|
56 |
> Anyway, when pretty much nobody uses a particular software anymore, it |
57 |
> won't be very feasible to use that software. |
58 |
|
59 |
Nobody said that when debian announced to shut down their FTP servers. |
60 |
Debian is not the king to rule the internet. You shouldn't care when |
61 |
they shut down their FTP services. It doesn't matter to the rest of the |
62 |
world using the internet. |
63 |
|
64 |
> > There's always dropbox |
65 |
> |
66 |
> Well, dropbox sucks. I got a dropbox link and it didn't work at all, |
67 |
> and handing out the data to some 3rd party is a very bad idea. It's |
68 |
> also difficult to automate things with that. |
69 |
|
70 |
There's also owncloud (or whatever it is called now). You can automate |
71 |
things by deploying a sync application on your clients side. |
72 |
|
73 |
|
74 |
-- |
75 |
Regards, |
76 |
Kai |
77 |
|
78 |
Replies to list-only preferred. |