Revising Unit's supported platforms

[callahad]

Today, Unit advertises support for a myriad of operating systems and CPU architectures, many outdated or obscure (Solaris! Itanium!)

I'd like us to revise that set to focus on more prevalent platforms.

We don't need to be as rigorous as Rust's Target Tier Policy, but it's good inspiration.

Proposal

Tier 1

Guaranteed to work.

• x86_64-linux-gnu
• aarch64-linux-gnu
• aarch64-apple-darwin

Tier 2

Best effort, not rigorously tested.

• x86_64-freebsd
• x86_64-linux-musl
• aarch64-linux-musl

Explicitly Unsupported

• Windows
• 32-bit architectures

Everything Else

We'll consider patches, but all bets are off.

Questions

1. Does this make sense? Am I missing anything obvious?
2. Should aarch64-apple-darwin be Tier 2 instead of Tier 1?
3. Do we need to explicitly talk about compilers? And if so, are we GCC-only or GCC + Clang?

[ac000]

Unit is actively packaged for Alpine Linux.

Sergey Osokin maintains the FreeBSD port.

I'd expect the tier two targets to continue working just as well as tier one.

Do we need to explicitly talk about compilers? And if so, are we GCC-only or GCC + Clang?

We support both GCC and Clang, this is good, they both find different issues.

I don't think we need to say much other than any version of GCC/Clang within the last decade or so can build Unit.

[andrey-zelenkov]

I've asked to summarize the differences between Tier 1 and Tier 2 for Rust policies, and at first glance, many criteria seem irrelevant to us or should be redefined:

So, I suggest starting by defining the criteria that we actually mean for our tiers (having table like this would also help). For example, we can keep some criteria like guarantees, CI + testing, documentation, etc., and add specific ones for us, such as release blockers, security requirements, performance requirements, etc. This will also help extend this scheme if some platforms are outliers (e.g., Darwin, which is used for presentation purposes and usually does not block the release process but should be maintained at a certain level).

[javorszky]

Is that table a summary of https://doc.rust-lang.org/rustc/target-tier-policy.html ?

[avahahn]

should aarch64-apple-darwin be tier 2 instead of tier 1

Given that apple continues to push their own custom ARM silicon I dont think that would be wise. ARM macbooks will be standard issue to many application developers at many large companies for the foreseeable future.

[javorszky]

I'm generally of the idea that good enough is good enough. Let's target the important systems and the popular systems, and let's not spend time and effort on niche systems and hand that off to the community.

My thinking here is that we're few, we need to do a few things well, and we can't do that if we're stretched too thin trying to support platforms that only a few people / companies use.

Once Unit is big enough and we have more support from corporate and we can increase the team, and we have a good flow of communication between us and the users and we know what they want, then we'll be in a better position to make data based calls on what to support and what not to prioritize.

---

I agree with @avahahn on keeping aarch64-apple-darwin a tier 1 target, especially in light of apple announcing their cloud computing solution.

---

With regards of my expectations of tier 1 v tier 2:

Tier 1 should be fully supported on the target system, which means on a completely new and empty system, with nothing installed, users should be able to install unit using one command, and have it work correctly without any additonal input needed from the user. This ideally means the system doesn't need additional packages installed alongside unit itself, or if it does, it can take care of it in userspace without needing sudo or equivalent.

Tier 2 should be supported, but some manual tinkering and making sure required packages are installed are okay, but once those are done, unit should work mostly the same barring a few edge cases.

In both cases the minimum is that CI tests should pass without fail and builds should succeed, I think this should be the bare minimum.

[ac000]

I think we have very different idea's of what the tiers mean...

I take them to mean that say tier 1, Unit builds and runs optimally. For tier 2, unit should build but may or may not run optimally, if say it's had to fallback to some slower implementation of something. e.g poll(2) vs say epoll(7), or may not take advantage of some hardware feature... or we temporarily break on musl + clang systems (which we have in the past, though we now have CI in place for such systems).

[javorszky]

I absolutely think we have very different ideas of what the tiers mean. Do they have specific and defined meanings in this (as in software engineering support) context besides "this is more supported than that"?

[callahad]

We get to decide :) Hence this thread.

My original intent is closer to Andrew's: We are proactively ensuring Unit builds, passes extensive tests, and functions optimally on Tier 1 targets. Tier 2 is... well, it'll build. Probably. Maybe not if you use a weird version of clang. And performance might suck on musl; we won't regularly benchmark against that.

[callahad]

(FWIW, I think the experience goals in the comment above sit at the intersection of this discussion and #1333 -- if you're on macOS w/ Apple Silicon, or the latest Ubuntu, or anything with Docker then you should have a frictionless experience as outlined above)

[javorszky]

Having read Revising Distro Packages discussion after responding to this, I'm changing my opinion on support of Tier 2 systems. Best effort is fine, we should aim to keep them working, and this is where we could maybe involve the community?