Re: Description of tasks
David Weinehall <firstname.lastname@example.org> writes:
> On Fri, Jul 16, 2004 at 11:47:17PM +0200, Ingo Juergensmann wrote:
>> Me too... but ask for the reasons why people get upset and not just the
>> symptom that they are upset.
> Look, it's been established long ago that you and some others cannot
> communicate with some persons in the project. Communication is a
> two-way street, so there's probably problems on both sides. It has,
> however, also been established that you have been successful in getting
> answers to at least some questions using our DPL as a proxy.
> So let's use some simple logic, shall we?
> A <=/=> C
> A <===> B <===> C
> Now, if you want to reach C, and a firewall (just to put it in terms
> of computer communication) blocks direct access to C, you have to find
> another way to reach C. Conveniently, there is a proxy that you've
> used before, and that you know works. The proxy B passes information on
> to (and from) C. So, your options are:
> a.) No communication (not desirable)
> b.) Complain about the situation to the network administrator until he
> either removes the firewall, shuts down the service C altogether,
> or removes your access to the proxy
> c.) Use the proxy (proven to work), and maybe, just maybe, in time
> gain enough respect from the network administrator to be able to
> get direct access to C
Option (c) has been used as well as using D or E as proxy as well as C'
(other ftp-master member).
No result. The use of proxies has failed in this case.
> The choice is yours. I know what I would have chosen.
> Of course, in real life, there is no network administrator, but rather
> the service C that decides the transmission policy, but from your
> position, that doesn't really matter.
> Yes, it's a pity that you don't have direct access, that slows things
> down. But slow access is almost always preferable to no access.
There isn't even indirect access this time.
> Regards: David Weinehall
PS: FYI Ingo has nothing to do with amd64.