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