The arguments seem... really weak ? They just linked to some random obscure bug and an obscure OS not being supported in containers (and I'd imagine solution being "just bring your own runner").
I have... questions about Zig leadership
The arguments seem... really weak ? They just linked to some random obscure bug and an obscure OS not being supported in containers (and I'd imagine solution being "just bring your own runner").
I have... questions about Zig leadership
> obscure OS not being supported
Believe it or not, there are platforms outside of the big 3.
The GitHub Actions runner does not work on FreeBSD, NetBSD, OpenBSD, and illumos, all of which are operating systems we either have existing support for, or intend to start supporting properly soon. (We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.)
And that's ignoring CPU architectures; the upstream GitHub Actions runner only supports x86 and aarch64. We had to maintain a fork that adds support for all the other architectures we care about such as riscv, loongarch, s390x, etc. We will also likely be adding mips64 and powerpc64 to the mix in the future.
Even IBM have to maintain an s390x fork because Microsoft can't even be bothered to accept PRs that add more platforms: https://github.com/uweigand/runner
> We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.
That's great. I hope it works out, and you have CI for NetBSD, OpenBSD, and illumos, too.
Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.
It's a shame GitHub doesn't have native CI even for FreeBSD on x86-64. I can see the economic case against it, of course. That said, the third-party Cross-Platform GitHub Action (https://github.com/cross-platform-actions/action) has made Free/Net/OpenBSD CI practical for me. I have used it in many projects. The developer is currently working on OmniOS support in https://github.com/cross-platform-actions/omnios-builder.
> Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.
In fact, we do already have cross-compilation support for NetBSD (and FreeBSD). But we currently only "test" NetBSD by building the language behavior tests and standard library tests for it on Linux, i.e. we don't actually run them, nor do we build the compiler itself for NetBSD. Native CI machines will allow us to fill that gap.
As it happens, Go's cross-compilation support does indeed make our lives easier for provisioning CI machines since we can build the Forgejo Runner for all of them from one machine: https://codeberg.org/ziglang/runner/releases/tag/v12.0.0
> They just linked to some random obscure bug
A bug that they have encountered, have reported, with a description of the root cause, and has not been fixed. A bug that has wasted their time and money.
Do the arguments have to be strong? I do not think they need to provide any justification. If the core developers decided that they would be more happy (or less miserable) with a different service, then let them.
If they are not why bother ?
"We don't like being hosted under microsoft due their business practices" is perfectly fine argument, no need to nitpick bugs out of bugtracker for justification
I mean, if they've been regularly hitting said bug, does it matter how obscure it is? If I were using a tool that was broken for me personally, I'd be ditching it, too; with absolutely zero regard to whether the tool works for others.