431–436 of 436 posts
Earlier quoted context omitted.
But wait for the user to have a week-long job running for three days before you do it. That way they have to explain to their boss why there is now a 3 day delay.
It's critical? Don't use hobbyist software for that then. Take Debian or CentOS or something else with a non-cavalier development culture.
Earlier quoted context omitted.
Debian is a bad choice if you want to package go applications (or rust apps, for that matter). Debian requires that all those little static dependencies be individually packaged. Common container software like lxd, podman, and umoci are not found in Debian. The following distributions package LXD (that I know of): * Void Linux * Alpine Linux * Arch Linux * Gentoo Some of those are more suitable for production install…
Do you happen to know _why_ Debian decided to require that for Go projects? It's so absurdly complicated. I've been looking into .deb packaging for Caddy but it really feels like they require us to jump through too many hoops to make it happen. I'd much rather just ship a prebuilt binary.
Security. Dynamically linking stuff is always going to be better than statically linking. Do you trust upstream to keep track of security issues and rebuild in the absurd dependency tree that is Golang software? Or the multi-year old effort which is the current Debian security team?
The reason why it's absurdly complicated is solely on the Golang team, not Debian.
Earlier quoted context omitted.
I've been looking forward for this work to come to something working for some time already, but it's been already 3 years I've eyed on it, is it now coming to something working "soon"?
Debian is a bad choice if you want to package go applications (or rust apps, for that matter). Debian requires that all those little static dependencies be individually packaged. Common container software like lxd, podman, and umoci are not found in Debian. The following distributions package LXD (that I know of): * Void Linux * Alpine Linux * Arch Linux * Gentoo Some of those are more suitable for production install…
Earlier quoted context omitted.
Hear hear. I imagine for dogfooding, LXD is only packaged in snap, so we can't use apt as the source anymore. After migrating, an upstream push to a 'stable' LXD snap channel introduced a regression that borked our environments, and there was no way to: 1. prevent machines in the fleet from pulling the broken LXD update 2. rollback broken machines to the previously working LXD version on the same channel, since it no…
Yes, the situation with LXD packaging is ridiculous. I always wondered, do the maintainers really use it themselves for anything non-trivial?
It's clearly not production stuff, but it works very well for a quick test bed before production deployments.
Earlier quoted context omitted.
I came to the realization that my home server doesn't need Ubuntu, it needs Debian.
All this shit actually drove me to NetBSD for my home server