[squid-dev] What os/cpu platforms do we want to target as a project?

[Amos Jeffries]

On 5/12/21 22:44, Francesco Chemolli wrote:
> Hi all,
>    continuing the conversation from
> https://github.com/squid-cache/squid/pull/942#issuecomment-986055422
> to a bigger forum
> 
> The discussion started out of a number of PRs meant to remove explicit
> support for obsolete platforms such as OSF/1, NeXT or old versions of
> Solaris.
> 
> I that thread I move forward a list of platforms that in my opinion we
> should as a project target, and while of course we should not
> explicitly prevent other platforms from being built on, we should also
> not disperse our time supporting complexity for the sake of other
> os/cpu combos .
> 
> The rationale is that we should focus our attention as a project where
> the majority of our userbase is, where users mean "people who build
> and run squid".
> 

I do not accept that a few hacks for old OS are causing pain to core 
developers simply by bitrotting in untouched code.

Removing things because the majority of users are not using it would 
mean we become a Linux-only project and thus actively push people out of 
the community unnecessarily. There are active benefits gained in the 
form of better code, bug detection, and community inclusiveness from 
maintaining portable code.


FTR; The criteria informing my OS removal decisions so far have been:

  a) Squid-3 has support for any OS which has a chance at providing C++ 
tools. Inheriting from the Squid-2 support for any ancient OS that had 
someone willing to provide patches.

  b) Squid-4+ require C++11 toolchain. This eliminates a lot of very old 
OS code. Especially those which have no vendor/distro have little chance 
at providing a modern toolchain.

  - At times the vendor/distro supporting that OS provides 
toolchains/support in ways that no longer need our hacks (eg PR 944 m88k 
supported as normal NetBSD/OpenBSD builds, PR 943 likewise as QNX or 
MacOS builds).

  -  At times our hack is for a version of OS which the vendor(s) 
provide (and/or require) admin to use a newer version of Squid for. Our 
usual distro hack removals.

  c) OS which are outdated (newer version supported by the vendors) need 
a reasonable ability for any admin wanting to manually build their Squid 
able to do so. If we know of any admin wanting the code to remain it can 
stay unless we have a clear reason to remove. (eg PR 942)


NP: now that Squid has formally dated releases I have a timeline for 
support forcasts. (eg PR 942 vendor LTS schedule vs Squid-6 release)



> We have no way of knowing who is installing squid, we don't have
> telemetry, so we will need to do a bit of guesswork, based on the
> assumption that people who deploy squid are rational; as a consequence
> of that, we can assume that they will go for the solution that gives
> them most bang for buck ("buck" being money and time).
> 
> What are the main use cases for squid users? (again, guesswork, please
> feel free to add more)
> 1. forward proxy in enterprise or ISP
> 2. reverse proxy in datacenter
> 3. forward proxy in small or embedded environments
> 


IME, (1) and (2) have switched places in the past 5 years for actual 
usage. Though (1) people are more vocal with SSL-Bump problems.


  4. protocol translation gateways

Historically FTP and Gopher to HTTP. Recent years IPv6/v4 conversion. 
Plus latest Browsers dropping FTP support has brought back FTP gateway 
translation popularity.


We should be in the thick of HTTP 1/2/3 conversion, but blockers on that 
work have completely eliminated Squid from that section of the market. 
People wanting that go to Haproxy instead.



> What are the Os/CPU combos that we can expect to find in these environments?

Ubuntu is a large chunk of user base and that alone requires a large 
range of architectures (see https://buildd.debian.org/) to get through 
Debian. That includes BSD and microkernel builds, not just Linux.

So, IMO specific machine architectures are not much concern to "us". The 
toolchains and vendors take care of that part so long as we provide 
half-decent code.


> x64 is likely to be found in all of them, and the OSes most likely to
> be used are all sorts of Linux, FreeBSD, OpenBSD, Windows.
> For the third use case (and possibly more and more of the second in
> upcoming years), we can consider arm64, arm32 and possibly MIPS with
> Linux. There might be a niche of NetBSD users here, hard to tell.
> 
> By now it makes no economic sense to run Squid on large Unix boxen.

Worse decisions have been sighted from management levels and not every 
admin has a choice. I don't think this is a strong enough argument for 
it to be relevant to this discussion.



> 
> What do we get as a project out of this?
> - Mainly code simplification. Fewer portability subcases makes for
> easier to understand and modify code

When it comes to portability the outcome is more ironic. The lack of 
special-cases means less pressure to have clear concept design, 
abstraction/boundaries between actions (modularity). So large code like 
Squid can become more complex than simple.

It is more work in total to design simple than complex/ad-hoc. 
Portability gives a clear justification for that design work, does not 
add/remove from the amount of it necessary to output simple code.


> - More clarity about our target use cases

That is a matter of features/protocols not portability.


> - better coverage in our testing for our explicit target use cases
> 

Agreed.

Amos