On Thu, 4 Dec 2003, Mark A. Lewis wrote:
> > Because Squid is open source while ISA is not?
>
> Certainly an advantage if you have the resources to do something with
> that source or someone has already done it.
Open source is not only about having access to the source, it is also a
political question on how you want providers to operate.
I have several customers who have learnt this over the years, all starting
out as microsoft only.
> > Because Squid does not make you further dependent on Microsoft than
> you already are?
>
> Eh, I don't know that this is a real advantage. More opinion, and not
> very subjective.
To me it is an advantage. I do not want any business I am operating to be
totally dependent on a single provider. I prefer having a choice and being
aware of that there are choices.
> >Because by using Squid you are free to build the proxy solution you
> want to have rather than what Microsoft thinks you should have?
>
> Can you elaborate about what proxy solutions can be achieved with squid
> that cannot be achieved with ISA? ISA supports hierarchys, peering and
> every other configuration that Squid supports that I am aware of.
Some strengths
* Very flexible authentication, if you should require any other forms of
authentication than the NT domain.
* Even more flexible access controls, even if a little arcane to
configure (Squid access controls is unfortunately designed by programmers,
not for humans)
* Very easy redirection of common requests to local mirrors.
and a lot more interesting things I am not sure ISA can do.
> >Because you are interested in what Squid can provide?
>
> What does it provide that ISA cannot?
This argument was not intended to say that Squid provides something which
ISA cannot (which is certainly true, but so is also the reverse), but more
in the lines of "squid is fun". If you have a interest to see if Squid can
solve the problem and it looks like it can then there is a benefit of
trying to find out if this is true.
> 1)If you need NTLM authentication and are not a *nix person you almost
> certainly pull your hair out trying to get it to work on Squid. It
> suffers from the same documentation vacuum that many open source
> projects have. Squid itself is very well documented, but the NTLM piece
> is woefully lacking. You have to decide if you are willing to undertake
> this, and if you can maintain it.
This is probably because the programmers consider it a too simple task.
Install Samba-3 according to the Samba-3 documentation and then use the
ntlm_auth helper shipped with Samba-3. But indeed there is some
complications which deserves documentation.
There was a simple step-by-step guide posted not long ago on this subject.
> 3) Do you require the accountability of real support channels or can you
> use mailing-lists and Google? This is for both the OS and Squid. There
> is commercial support available but I do not know what the costs are
> compared to ISA.
MARA Systems is more than happy to help you on this issue if you like.
> 4) There are no promises that Squid will be supported in the future. As
> much as some may not like it, MS will be around for a while.
There is no question that Squid will be around for a substantial time. As
long as there is a reasonable user base there will be providers of
commercial support available and continued development, and with it's open
source nature it is a open market for support so even if one support
provider disappears there will always be new ones willing to support the
ones who need support.
Squid has now surived for close to 8 years (10 or so if you include the
time it was Harvest Cached). During all this time Squid has not been
dependent on a single person or entity but a collaborative work, even more
so in the later years. In fact it can be seen that the less dependent on a
single entity Squid is the more rapid it develops. To some this may seem
like a contradiction to some traditional business people but is a truth in
open source development due to the different framework of development.
Regards
Henrik
Received on Thu Dec 04 2003 - 17:42:15 MST
This archive was generated by hypermail pre-2.1.9 : Thu Jan 01 2004 - 12:00:05 MST