What does an open source project get from this? Supporting s390x can be a pain. Their CI instances are over provisioned and time-out, sometimes odd failures due to the odd architecture, maybe performance issues. That's more headaches and toil from volunteers. So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
> what's in it for a project to deal with this extra architecture
You’d be surprised the number of companies who really want to run something on an obscure platform, and will pay $$$ to port stuff to it. Often the thing being ported isn’t even open source, it is some proprietary product, but that proprietary product has open source dependencies, and so someone ends up paid to port them to the obscure platform, to even try to upstream the port if the maintainers will take it.
Years ago, I knew of a small company which sold a CMS (I was going to work for them, but the job fell through when they couldn’t pay me enough); the CMS was proprietary, but it ran on an open source stack (LAMP). Some random customer said they’d only buy it if it was ported to IBM i (PASE, the AIX emulation environment), and they were willing to pay for the port, so it happened.
Later on, I worked for Oracle, and ended up on a project to port some ERP-related product to AIX - all because we had a big customer willing to pay millions for this product, but only if we made it run on AIX. And in the process I found an AIX-specific bug in JNA (the open source Java FFI library), and ended up helping the JNA developers to fix it
What does an open source dev get out of their work at all? Satisfaction?
For the "traditional" open source model of give away the software and sell the support, s390x customers could be fantastic customers: love paying for support, lots of $$$, super sticky once you get them.
But yeah for a random indie dev the PITA makes it harder.
> Their CI instances are over provisioned and time-out
I can't speak to their managed Jenkins offering, but FWIW, we've had no major trouble running Zig's CI on 3 s390x-linux VMs, each with 8x z15 vCPUs and 32 GB of RAM.
They are definitely over-provisioned, though, so we have the job timeouts set ~3 hours higher than they ideally should be to deal with load spikes. But after we dialed those timeout values in, it's been smooth sailing from there. I'd even say it's one of our most stable CI platforms now.
I did reach out to Bruce Gilkes about the over-provisioning and he informed me that they are planning an upgrade to z17 later this year, so hopefully that'll improve the situation.
> What does an open source project get from this? ... So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
The way I look at it, if Zig is going to be a serious C competitor, it must run in all the places that people run C in. Plus I just find it fun to do porting work since it involves a whole bunch of learning.
> So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
I submitted the story, and I'm mentioned in it.
For me, it's about demonstrating my stuff runs everywhere Go does.
In particular, this makes s390x the only bigendian architecture I can test on "actual hardware" (vs. QEMU binfmt emulation).
this literally is about ibm providing free cloud infrastructure and offering support for the community. what failures are you talking about? s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance, which is why it is still in use. the incentives both for the community supporting it and the manufacturer supporting the community seem pretty evident to me.
> this literally is about ibm providing free cloud infrastructure and offering support for the community.
My comment is literally about the same thing. Does IBM provide x86 and ARM workers or s390x only?
> what failures are you talking about? s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance
I am talking about timeouts in CI blocking the whole pipeline, odd failures with JVM not working, hitting some jit corner cases, I am talking about kernel level concurrency bugs, and so on. I've seen them all. How much should a volunteer oss library maintainer spend debugging that?
> s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance, which is why it is still in use.
It is so me. I don't see a reason to care for it.
> the incentives both for the community supporting it and the manufacturer supporting the community seem pretty evident to me.
Not evident to me. Unless there is some other kind of incentive involved, they agree to fix other bugs, provide CI workers for other architectures, pay for support and so on.
What does an open source project get from this? Supporting s390x can be a pain. Their CI instances are over provisioned and time-out, sometimes odd failures due to the odd architecture, maybe performance issues. That's more headaches and toil from volunteers. So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
> what's in it for a project to deal with this extra architecture
You’d be surprised the number of companies who really want to run something on an obscure platform, and will pay $$$ to port stuff to it. Often the thing being ported isn’t even open source, it is some proprietary product, but that proprietary product has open source dependencies, and so someone ends up paid to port them to the obscure platform, to even try to upstream the port if the maintainers will take it.
Years ago, I knew of a small company which sold a CMS (I was going to work for them, but the job fell through when they couldn’t pay me enough); the CMS was proprietary, but it ran on an open source stack (LAMP). Some random customer said they’d only buy it if it was ported to IBM i (PASE, the AIX emulation environment), and they were willing to pay for the port, so it happened.
Later on, I worked for Oracle, and ended up on a project to port some ERP-related product to AIX - all because we had a big customer willing to pay millions for this product, but only if we made it run on AIX. And in the process I found an AIX-specific bug in JNA (the open source Java FFI library), and ended up helping the JNA developers to fix it
What does an open source dev get out of their work at all? Satisfaction?
For the "traditional" open source model of give away the software and sell the support, s390x customers could be fantastic customers: love paying for support, lots of $$$, super sticky once you get them.
But yeah for a random indie dev the PITA makes it harder.
> Their CI instances are over provisioned and time-out
I can't speak to their managed Jenkins offering, but FWIW, we've had no major trouble running Zig's CI on 3 s390x-linux VMs, each with 8x z15 vCPUs and 32 GB of RAM.
They are definitely over-provisioned, though, so we have the job timeouts set ~3 hours higher than they ideally should be to deal with load spikes. But after we dialed those timeout values in, it's been smooth sailing from there. I'd even say it's one of our most stable CI platforms now.
I did reach out to Bruce Gilkes about the over-provisioning and he informed me that they are planning an upgrade to z17 later this year, so hopefully that'll improve the situation.
> What does an open source project get from this? ... So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
The way I look at it, if Zig is going to be a serious C competitor, it must run in all the places that people run C in. Plus I just find it fun to do porting work since it involves a whole bunch of learning.
> So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
I submitted the story, and I'm mentioned in it.
For me, it's about demonstrating my stuff runs everywhere Go does.
In particular, this makes s390x the only bigendian architecture I can test on "actual hardware" (vs. QEMU binfmt emulation).
> In particular, this makes s390x the only bigendian architecture I can test on "actual hardware" (vs. QEMU binfmt emulation).
NetBSD can run a Raspberry Pi in BE mode, if you want another option.
But as long as I'm on GitHub, it's much easier to just add this (and the RISE RISC-V runners, and a few QEMU targets) to CI.
PS: I do also test NetBSD in CI.
this literally is about ibm providing free cloud infrastructure and offering support for the community. what failures are you talking about? s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance, which is why it is still in use. the incentives both for the community supporting it and the manufacturer supporting the community seem pretty evident to me.
> this literally is about ibm providing free cloud infrastructure and offering support for the community.
My comment is literally about the same thing. Does IBM provide x86 and ARM workers or s390x only?
> what failures are you talking about? s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance
I am talking about timeouts in CI blocking the whole pipeline, odd failures with JVM not working, hitting some jit corner cases, I am talking about kernel level concurrency bugs, and so on. I've seen them all. How much should a volunteer oss library maintainer spend debugging that?
> s390x is not an "exotic" architecture by any stretch and is pretty top-notch in terms of availability, reliance and performance, which is why it is still in use.
It is so me. I don't see a reason to care for it.
> the incentives both for the community supporting it and the manufacturer supporting the community seem pretty evident to me.
Not evident to me. Unless there is some other kind of incentive involved, they agree to fix other bugs, provide CI workers for other architectures, pay for support and so on.
Open source on the most closed and expensive hardware platform available where IBM charges you for every instruction cycle.