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

[Francesco Chemolli]

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".

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

What are the Os/CPU combos that we can expect to find in these environments?
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.
Maybe some corporate can convince some captive account to run a
reverse proxy on AIX/POWER, but I don't see anyone willing to pay tens
of thousands of dollars in maintenance contracts on expensive UNIX
iron to run a service that can run as well if not better on Linux/x64

Given these reasonings, I would recommend that we support as main targets:
- Linux on x64, arm64, arm32 and, if we can, MIPS
- FreeBSD, OpenBSD on x64
As best-effort:
- Windows on x64, with the aim of eventually promoting to primary target
- Darwin on x64 and maybe eventually arm64
- NetBSD on x64

If anyone in the community wants to support/maintain extra OSes or
architectures, they're very welcome to do so; I expect that the target
audience is of enthusiasts who have the technical skills to do so,
largely independently.

What do we get as a project out of this?
- Mainly code simplification. Fewer portability subcases makes for
easier to understand and modify code
- More clarity about our target use cases
- better coverage in our testing for our explicit target use cases


Let's discuss

-- 
    Francesco