@whitequark which one is the latter?
-
@navi @SRAZKVT my position on distributions boils down to "it is pretty weird and otherwise unprecedented that we've normalized it that once you release software some other group of people (who don't really understand how it works) is going to build and publish it, giving you little to no say in the matter, but leaving you responsible for support in the end". so far as this is true i think the value distributions provide to me as a developer, and also as a user, is neutral to negative. Debian is the worst at this but I think the entire model should be replaced
@whitequark @SRAZKVT
and i think that staggering software distribution is a benefit for the user, as a ton of developer do not ever consider setups that differ from their on even in the slightest -- as an example nix and gentoo packagers so often send dozens and dozens of patches upstream fixing build systems that had baked in expectations
i've personally sent patches out fixing autotools issues with cross-building a handful of packages from portage
sure there is distros whose people make no effort to learn about the software they package, nor to fix issues, but most if not all packagers i've ever talked to are not like that at all, and that includes packagers for gentoo, nix, guix, alpine, void, and a few debian ones (though i am *well* aware of many issues debian in general has with packaging)
decent distros have their own bug tracker, on gentoo the majority of bugs go there, before going upstream (if the problem turns out to not be with the downstream packaging) -- it does help when the package has some branding build-time flags where we can replace e.g. the upstream issues tracker url with our bug tracker, makes it easier to direct users there first
staggered releases are to the benefit of users, if users had gotten the newest xz as soon as the developer pushed it, instead of having it land on a testing branch first, how many more people wouldn't have been affected day 1
in particular also gentoo held back the shadow package from hitting stable for a while because new versions had a ton of refactoring of security sensitive code, so the packager wanted to be sure it was all okay before pushing it for everyone (though if one wanted, they can select per-package ~$arch, to enable testing packages on said $arch)
--
and redistribution being seen as weird is odd to me, the nature of foss is collaborative and communitarian, and not unique to foss, we're pretty okay with libraries redistributing books -
@whitequark @SRAZKVT
and i think that staggering software distribution is a benefit for the user, as a ton of developer do not ever consider setups that differ from their on even in the slightest -- as an example nix and gentoo packagers so often send dozens and dozens of patches upstream fixing build systems that had baked in expectations
i've personally sent patches out fixing autotools issues with cross-building a handful of packages from portage
sure there is distros whose people make no effort to learn about the software they package, nor to fix issues, but most if not all packagers i've ever talked to are not like that at all, and that includes packagers for gentoo, nix, guix, alpine, void, and a few debian ones (though i am *well* aware of many issues debian in general has with packaging)
decent distros have their own bug tracker, on gentoo the majority of bugs go there, before going upstream (if the problem turns out to not be with the downstream packaging) -- it does help when the package has some branding build-time flags where we can replace e.g. the upstream issues tracker url with our bug tracker, makes it easier to direct users there first
staggered releases are to the benefit of users, if users had gotten the newest xz as soon as the developer pushed it, instead of having it land on a testing branch first, how many more people wouldn't have been affected day 1
in particular also gentoo held back the shadow package from hitting stable for a while because new versions had a ton of refactoring of security sensitive code, so the packager wanted to be sure it was all okay before pushing it for everyone (though if one wanted, they can select per-package ~$arch, to enable testing packages on said $arch)
--
and redistribution being seen as weird is odd to me, the nature of foss is collaborative and communitarian, and not unique to foss, we're pretty okay with libraries redistributing books -
@whitequark @SRAZKVT i don't like software patches beyond "fix major $bug that didn't land upstream yet" either! not a coincidence most distros i mentioned ship vanilla software
-
@navi @SRAZKVT i agree about staggered deployment but that is neither specific to, nor requires distros. i think go is planning to do it ecosystem wide, for example
i also agree that a lot of software bakes developers' assumptions into it but i don't see anything packagers like as universal good. FHS was a mistake. non-reproducible builds are a mistake. non-hermetic builds are a mistake... some of these things distros get right, some very much not
-
@whitequark @SRAZKVT i don't like software patches beyond "fix major $bug that didn't land upstream yet" either! not a coincidence most distros i mentioned ship vanilla software
@navi @SRAZKVT if all distros do is ship vanilla software i'd much rather save the collective effort and invest in something like flatpak
flatpak is (sigh) kind of terrible, as i've been studying it in detail just yesterday night, but it's the direction i care about here more so than the exact implementation. it could be a nix flake for all i know. though nix is also kind of terrible (i use it a lot, i would know)
-
@navi @SRAZKVT if all distros do is ship vanilla software i'd much rather save the collective effort and invest in something like flatpak
flatpak is (sigh) kind of terrible, as i've been studying it in detail just yesterday night, but it's the direction i care about here more so than the exact implementation. it could be a nix flake for all i know. though nix is also kind of terrible (i use it a lot, i would know)
@whitequark @SRAZKVT flatpak also has assumptions built in, flatpak (or rather, flathub) is a distro
you can't have one packaging format and expect it to work for everyone, gentoo supports 14 cpu architectures (amd64, arm, arm64, ppc, ppc64, x86, alpha, hppa, loong, mips, riscv, s390, spark, m68k)
flathub by what i can find has... amd64, x86, arm, arm64, and that's it?
not to mention how gentoo systems differ from nix which differ from guix, having a single packaging format with a single distribution channel would be hell for anything that doesn't conform to the notions of whomever built the tooling for that package format
nix is better but it's still not a one-size fits all, there's no such thing -
@navi @SRAZKVT if all distros do is ship vanilla software i'd much rather save the collective effort and invest in something like flatpak
flatpak is (sigh) kind of terrible, as i've been studying it in detail just yesterday night, but it's the direction i care about here more so than the exact implementation. it could be a nix flake for all i know. though nix is also kind of terrible (i use it a lot, i would know)
@whitequark@social.treehouse.systems @navi@social.vlhl.dev @SRAZKVT@tech.lgbt to add to this discussion, I am a huge flatpak advocate not because the tech is the best, but because it exists and has proven to work giving developers a consistent target for linux systems
you want to package it into your own distro? sure go ahead, but as the underlying dependencies are no longer the same support is up to the developer to decide AND there is a "canonical" build to test these on -
@navi @SRAZKVT i agree about staggered deployment but that is neither specific to, nor requires distros. i think go is planning to do it ecosystem wide, for example
i also agree that a lot of software bakes developers' assumptions into it but i don't see anything packagers like as universal good. FHS was a mistake. non-reproducible builds are a mistake. non-hermetic builds are a mistake... some of these things distros get right, some very much not
@whitequark @SRAZKVT
sure none of it may exclusive from distros, but the point is that distros (should, nay, must) look after their users -- the main point is being communitarian, not under exclusive control of the developer, e.g.
upstreams often don't do releases to fix big regressions, distros can patch those when needed
sometimes upstreams go haywire and the distro attempts to protect the users (newer keepassxc being masked on gentoo)
it's harder to do when the developer has complete control of the distribution method -
@chaos @resistor @whitequark refactoring is not a problem per se. The problem is that with zig, it's much easier to break things accidentally without noticing during the refactoring than it is with rust (where almost all such accidental breakages will simply result in a compile-time error).
@IngaLovinde @resistor @whitequark yeah we really value how rust's compiler is smarter than we are and points us to the exact issue rather than us having to break out a debugger
makes programming so much less energy intensive, rust's stdlib also maps very nicely to how our brain handles programming, it just requires a bit more upfront thinking of how to structure code/data, def worth the tradeoffs for us esp as we already have very little energy for programming -
@whitequark @SRAZKVT
sure none of it may exclusive from distros, but the point is that distros (should, nay, must) look after their users -- the main point is being communitarian, not under exclusive control of the developer, e.g.
upstreams often don't do releases to fix big regressions, distros can patch those when needed
sometimes upstreams go haywire and the distro attempts to protect the users (newer keepassxc being masked on gentoo)
it's harder to do when the developer has complete control of the distribution method -
@whitequark @SRAZKVT
and because it's riddled with dubious llms as well as being qt5, source, i talk with gentoo folks basically every day -
-
@whitequark@social.treehouse.systems @navi@social.vlhl.dev @SRAZKVT@tech.lgbt to add to this discussion, I am a huge flatpak advocate not because the tech is the best, but because it exists and has proven to work giving developers a consistent target for linux systems
you want to package it into your own distro? sure go ahead, but as the underlying dependencies are no longer the same support is up to the developer to decide AND there is a "canonical" build to test these on -
@whitequark @SRAZKVT
and because it's riddled with dubious llms as well as being qt5, source, i talk with gentoo folks basically every day@whitequark @SRAZKVT but there's other examples too, like the shadow package i listed on op
sure the maintainer didn't actually go haywire, but it was caution for weird commits being released -
@whitequark @SRAZKVT flatpak also has assumptions built in, flatpak (or rather, flathub) is a distro
you can't have one packaging format and expect it to work for everyone, gentoo supports 14 cpu architectures (amd64, arm, arm64, ppc, ppc64, x86, alpha, hppa, loong, mips, riscv, s390, spark, m68k)
flathub by what i can find has... amd64, x86, arm, arm64, and that's it?
not to mention how gentoo systems differ from nix which differ from guix, having a single packaging format with a single distribution channel would be hell for anything that doesn't conform to the notions of whomever built the tooling for that package format
nix is better but it's still not a one-size fits all, there's no such thing -
@whitequark @SRAZKVT
and because it's riddled with dubious llms as well as being qt5, source, i talk with gentoo folks basically every day -
-
@whitequark @SRAZKVT
that's exactly the point? there's people using s390, or mips, or riscv, but developers do not care
who does? distros that support those arches, try building software, fixes bugs on said software, send fixes upstream, like gentoo does *all the time*
"number of architectures" isn't an optimization target, there's no target, there's people wanting to use software on systems developers don't think of, know exist, or care about -- and there's distro packagers doing work for their communities to have that happen, sometimes they do it for themselves, most of the time they work on things that they won't ever use, so that their users can -
@whitequark @SRAZKVT
> eudev
here's a complete, albeit still experimental, complete reimplementation of systemd-udev: https://git.pinkro.se/Rose/gardenhouse/gardendevd.git/
made by, a gentoo user, it's capable of booting modern DEs like KDE
> if you mask all critical software
damage control and risk assessment is a thing -
@whitequark @SRAZKVT
> eudev
here's a complete, albeit still experimental, complete reimplementation of systemd-udev: https://git.pinkro.se/Rose/gardenhouse/gardendevd.git/
made by, a gentoo user, it's capable of booting modern DEs like KDE
> if you mask all critical software
damage control and risk assessment is a thing
