cmd/go,x/telemetry/config: collect the set of OS versions on which the go command is run

[adonovan]

When deciding to drop support for an OS version (e.g. #69839) it is useful to know how many people still use it. We can collect this information through telemetry. I propose that we do.

@findleyr

[seankhliao]

I wonder how much of a difference there is between developer machines where go is primarily run (where we'll get telemetry) and the deploy targets where compiled binaries are run (there were a few comments about appliance style customer systems on the Windows support thread)?

[apparentlymart]

Continuing the train of thought from @seankhliao's comment above...

I would expect that usage of a particular platform for actual development is likely to drop considerably faster than use of that same platform as a deployment target, since deployment targets typically have more cautious platform upgrade rhythms than developer workstations.

I could therefore imagine potentially making compromises where a specific platform gets phased out as a toolchain host while remaining as a cross-compilation target, if a target seems used more heavily for deploy targets than for actually running go. (Or, with more subtlety, perhaps a platform moves to a lower support tier as a toolchain host than it is as a target, at least for a transitional period.)

A deployed Go program cannot (and should not) collect telemetry itself, but perhaps collecting both the host and target information (i.e. the effective target selected by the GOOS and GOARCH values) would allow the latter to serve as a proxy for usage as deploy targets. Tracking both in terms of usage of the go tool might also make the two directly correlatable, to allow estimating answers to questions such as "Is Linux used as much as a development host as it is used as a deployment target?"

[adonovan]

I share your concerns about the difference between developer and deployment OSs, and we should try to make clear in the metadata of the metric that it refers to the OS on which the tools run, which is an imperfect measure of deployment.

The specific proposal here is about collecting OS version numbers, not mere GOOS values, which we already collect.

I'm not sure there's much quantitative signal in the noise of correlating host and target OS (or ARCH) pairs. Even when you primarily develop for a different primary OS (or ARCH), programs are portable enough that most of the time one builds for the host machine and runs tests locally.

[cagedmantis]

cc @golang/tools-team

[findleyr]

Thanks, I think this makes sense. See also https://research.swtch.com/telemetry-uses#windows7.

(Aside: this doesn't need to go through the main proposal process, just the telemetry proposal process).

I do share others' concerns that this is only measuring usage on go developer machines, which is only one type of usage we care about. Nevertheless, I think it is a useful indicator. Certainly it can tell us of true positives, even if it can't detect true negatives.

[rsc]

Quoting that page:

Answering these questions would require counters for each major operating system version like Windows 7, Windows 8, Debian Buster, Linux 3.2.x, and so on. There would be no need to collect fine-grained information like specific patch releases, unless some specific release was important for some reason (for example, we might want more resolution on Linux 2.6.x, to inform advancing the minimum Linux kernel version beyond 2.6.32).

So just to be clear, this should be coarse-grained when collected. For Linux that would mean truncating to x.y, not x.y.z.

[findleyr]

We're comfortable accepting this, provided the buckets are coarse, as @rsc said.

This is a non-trivial amount of work to implement, as instrumentation will vary by platform and bucketing may not be obvious. Nevertheless it would be nice to get this into 1.24.

[matloob]

In Go 1.23 we have a go/platform/host/<GOOS>/version:<MAJOR>-<MINOR> counter that's reported for Unix and Windows GOOSes.

Unfortunately, the mapping of Windows major and minor versions are all 10.0 for Windows 10, 11, Server 2016, Server 2019, and Server 2022 (see https://learn.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version). And those are the only versions of Windows we support for Go 1.21 and later... If we want that information we'd have to use the build number, which is also a counter in 1.23: go/platform/host/windows/build:<BUILD> and map those build numbers to the version names. I couldn't find an official source with the mapping, but assuming https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions is correct, there are currently 14 build numbers for Windows 10, 4 build numbers for Windows 11, and 11 for the Windows Server 2016+ versions. I'm not sure if that's too granular to record.