1 |
On 03/05/2017 22:04, lee wrote: |
2 |
> Alan McKinnon <alan.mckinnon@×××××.com> writes: |
3 |
> |
4 |
>> On 30/04/2017 03:11, lee wrote: |
5 |
>>> "Poison BL." <poisonbl@×××××.com> writes: |
6 |
>>> |
7 |
>>>> On Sat, Apr 29, 2017 at 3:24 PM, lee <lee@××××××××.de> wrote: |
8 |
>>>> |
9 |
>>>>> Mick <michaelkintzios@×××××.com> writes: |
10 |
>>>>> |
11 |
>>>>>> On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote: |
12 |
>>>>>>> On 25/04/2017 16:29, lee wrote: |
13 |
>>>>>>>> Hi, |
14 |
>>>>>>>> |
15 |
>>>>>>>> since the usage of FTP seems to be declining, what is a replacement |
16 |
>>>>>>>> which is at least as good as FTP? |
17 |
>>>>>>>> |
18 |
>>>>>>>> I'm aware that there's webdav, but that's very awkward to use and |
19 |
>>>>>>>> missing features. |
20 |
>>>>>>> |
21 |
>>>>>>> Why not stick with ftp? |
22 |
>>>>>>> Or, put another way, why do you feel you need to use something else? |
23 |
>>>>>>> |
24 |
>>>>>>> There's always dropbox |
25 |
>>>>>> |
26 |
>>>>>> |
27 |
>>>>>> Invariably all web hosting ISPs offer ftp(s) for file upload/download. |
28 |
>>>>> If you |
29 |
>>>>>> pay a bit more you should be able to get ssh/scp/sftp too. Indeed, many |
30 |
>>>>> ISPs |
31 |
>>>>>> throw in scp/sftp access as part of their basic package. |
32 |
>>>>>> |
33 |
>>>>>> Webdav(s) offers the same basic upload/download functionality, so I am |
34 |
>>>>> not |
35 |
>>>>>> sure what you find awkward about it, although I'd rather use lftp |
36 |
>>>>> instead of |
37 |
>>>>>> cadaver any day. ;-) |
38 |
>>>>>> |
39 |
>>>>>> As Alan mentioned, with JavaScript'ed web pages these days there are many |
40 |
>>>>>> webapp'ed ISP offerings like Dropbox and friends. |
41 |
>>>>>> |
42 |
>>>>>> What is the use case you have in mind? |
43 |
>>>>> |
44 |
>>>>> transferring large amounts of data and automatization in processing at |
45 |
>>>>> least some of it, without involving a 3rd party |
46 |
>>>>> |
47 |
>>>>> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB, |
48 |
>>>>> or even more. The mirror feature of lftp is extremely useful for such |
49 |
>>>>> things. |
50 |
>>>>> |
51 |
>>>>> I wouldn't ever want having to mess around with web pages to figure out |
52 |
>>>>> how to do this. Ftp is plain and simple. So you see why I'm explicitly |
53 |
>>>>> asking for a replacement which is at least as good as ftp. |
54 |
>>>>> |
55 |
>>>>> |
56 |
>>>>> -- |
57 |
>>>>> "Didn't work" is an error. |
58 |
>>>>> |
59 |
>>>>> |
60 |
>>>> Half petabyte datasets aren't really something I'd personally *ever* trust |
61 |
>>>> ftp with in the first place. |
62 |
>>> |
63 |
>>> Why not? (12GB are nowhere close to half a petabyte ...) |
64 |
>>> |
65 |
>>>> That said, it depends entirely on the network |
66 |
>>>> you're working with. Are you pushing this data in/out of the network your |
67 |
>>>> machines live in, or are you working primarily internally? If internal, |
68 |
>>>> what're the network side capabilities you have? Since you're likely already |
69 |
>>>> using something on the order of CEPH or Gluster to back the datasets where |
70 |
>>>> they sit, just working with it all across network from that storage would |
71 |
>>>> be my first instinct. |
72 |
>>> |
73 |
>>> The data would come in from suppliers. There isn't really anything |
74 |
>>> going on atm but fetching data once a month which can be like 100MB or |
75 |
>>> 12GB or more. That's because ppl don't use ftp ... |
76 |
>> |
77 |
>> I have the opposite experience. |
78 |
>> I have the devil's own time trying to convince people to NOT use ftp for |
79 |
>> anything and everything under the sun that even remotely resembles |
80 |
>> getting data from A to B... |
81 |
> |
82 |
> I guess you're lucky then. |
83 |
> |
84 |
>> (especially things that are best done over a |
85 |
>> message bus) |
86 |
> |
87 |
> Why would anyone try to transfer data over a message bus? Doesn't that |
88 |
> require extra wiring and specialized hardware? |
89 |
> |
90 |
>> I'm still not understanding why you are asking your questions. What you |
91 |
>> describe looks like the ideal case for ftp: |
92 |
> |
93 |
> it is |
94 |
> |
95 |
> Still nobody uses it, and apparently ftp usage is generally declining, |
96 |
> so I would expect there to be a better alternative. |
97 |
> |
98 |
>> |
99 |
>> - supplier pushes a file or files somewhere |
100 |
>> - you fetch those files later at a suitable time |
101 |
>> |
102 |
>> it looks like a classic producer/consumer scenario and ftp or any of |
103 |
>> it's webby clones like dropbox really it still the best tool overall. |
104 |
>> Plus it has the added benefit that no user needs extra software - all |
105 |
>> OSes have ftp clients even if it's just a browser |
106 |
> |
107 |
> The users don't know about that. |
108 |
> |
109 |
> |
110 |
|
111 |
|
112 |
OK, so here is what you have. |
113 |
|
114 |
You apparently must use ftp as pretty much nothing else works. |
115 |
You als claim that your users are too stupid to use ftp, and can't even |
116 |
type ftp://<something> into a browser. |
117 |
|
118 |
I'm sorry, but that's only marginally more believable than claiming |
119 |
keyboards are too complicated for your users. |
120 |
|
121 |
I doubt anyone here can help you - you do not have a technical problem, |
122 |
you have a people problem. I recommend the very first action you take |
123 |
now is to critically re-examine why you think of those users in the way |
124 |
you do and fix/amend what is going on inside your head. Then your way |
125 |
forward will be clear. |
126 |
|
127 |
|
128 |
-- |
129 |
Alan McKinnon |
130 |
alan.mckinnon@×××××.com |