Restore Solaris and Illumos support? about console HOT 6 CLOSED

Do those projects have access to machines running those operating systems for development and CI? We don't currently have any in containerd, so it's hard to maintain support.

from console.

We can build containerd/console with GOOS=solaris GOARCH=amd64 go build ./.... This does not require a machine running Solaris/Illumos.

The APIs used by containerd/console have existed for decades, and do not change. If they were to change, it would break a lot of existing software.

Therefore, building on solaris/amd64 is likely a sufficient test for now. The reverted commit already includes this build test for CI.

from console.

Do you know if there's actual users of the solaris builds on your side? Compiling is "one", but verifying everything works is another. The Solaris implementation in the code-bases (docker (moby), containerd, golang (including sparc support)) was carried out by the Oracle Solaris team at the time (who also ran test-infrastructure). That effort (and the team working on it) was sunset, after which much of the implementations went in disrepair.

While the implementation in this specific module may have "limited" impact (at least, currently), I know in other code-bases, the combination of build-tags became unwieldy fast, which can bring a lot of overhead when maintaining the code, and without a dedicated team working on Solaris support, that burden comes on "everyone else".

from console.

Do you know if there's actual users of the solaris builds on your side?

For my project, yes, for example see twpayne/chezmoi#1610 (OpenIndiana, i.e. Solaris/Illumos) and twpayne/chezmoi#2787 (not Solaris, but AIX, another old UNIX). I can't speak for the other users of the charmbracelet/bubbletea project, but given bubbletea is very popular, it's likely that several other projects indirectly rely on containerd/console's Solaris support.

While the implementation in this specific module may have "limited" impact (at least, currently), I know in other code-bases, the combination of build-tags became unwieldy fast, which can bring a lot of overhead when maintaining the code, and without a dedicated team working on Solaris support, that burden comes on "everyone else".

I agree with this sentiment, but would argue that a lot of low-level code (including, specifically, the C API calls required for console support) is stable and needs minimal maintenance. I would argue that the right time to stop support is when a change is required (e.g. a bug needs fixing or the code needs updating for refactoring or to support a new feature) and there is no one available to make that change. While the code is working without problems, it makes sense to keep it.

from console.

So a friendly fork is the likely outcome here. Of course, I would very much prefer that containerd/console restored the code that was working perfectly.

from console.