It is mostly indicative of another underlying issue, like glibc versions or so. But this also leads to weird situations with reproducibility for QE/error reporting. One of the reasons I also hated some distro wanting to devendor and use distro dependencies. This all makes it harder to have a consistent support matrix.
ivere27•1h ago
so, it's kinda build server, building golang sources in remote server?
then, download the built binary?
it seems to be useful for normal enduser I guess
guessmyname•43m ago
Oh, this web service is going to be such a nice target for hackers waiting to infect everyone who dares download random binaries. Centralizing “builds on demand” like this creates a pretty juicy supply-chain target. If the service gets popped, you’ve got a one-stop shop for shipping compromised binaries to every arch/OS combo. Convenient idea, but I’d only trust it with strong guarantees: reproducible builds, signed artifacts tied to commits, and a way to verify locally. Otherwise it’s basically “go install URL” with extra steps.
oefrha•11m ago
If you're in the market for this kind of thin convenience wrapper you might as well just vibe code a .goreleaser.yaml, .github/workflows/releases.yml and an install.sh. Takes a couple minutes, and you don't need to face angry users when this service is hacked/turns evil/shuts down. (Before anyone protests vibe coding, you're doing less due diligence by using this.)
duskwuff•6m ago
> The response of this request is a Golang binary compiled for the requested
operating system, architecture, package version, and the binary's name—using Go
1.17.x
Uh... Go 1.17 is almost five years old. (The current version is 1.26.) Why is this service using an ancient version of Go?
fractorial•1h ago
gbraad•1h ago