@whitequark which one is the latter?
-
@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 -
-
@whitequark rose also has a simple userdb and hostnamed (mostly for the sake of gnome), plus other tools like sysext, sysusers, ukify, and more, all reimplemented, all independent of each other and, obviously, of systemd
-
@whitequark @SRAZKVT i know what you're doing, yes -- and we've talked before once but that's highly irrelevant
distros don't misled people, it's best efforts, and often enough it works -
@SRAZKVT we are talking past each other. ocaml's situation that i'm mentioning is "if you are on certain platforms, then if you want your code faster, you're out of luck", in contrast to an approach where "if you are on certain platforms, you have to use certain extensions to make things faster". i think that while both have merit the former is severely underutilized. not every platform needs to be supported equally. this is not the same "baseline" as a "core without extensions" in that nobody except for the compiler maintainer and the people using that platform have to spend effort on a platform they never use.
for the latter part, rust has a 8-bit avr port that i've always found fairly senseless. it isn't a very nice thing to do to others to take a language where programmers could previously assume that a machine word is 32-bit and to extend it to a 8-bit microcontroller series which violates that assumption. i've always thought it should've just been left out of scope entirely
@whitequark rust on avr is crazy work. i thought 32bit arm microcontrollers are ubiquitous at this point, am i missing something? -
@whitequark @SRAZKVT
I feel that bootstrapping is essential to help counter supply chain and Trusting Trust attacks. -
@whitequark @SRAZKVT
I feel that bootstrapping is essential to help counter supply chain and Trusting Trust attacks. -
@whitequark @SRAZKVT
Oh yes, it's by no means an optimisation target, but it's a necessary one nonetheless. -
@whitequark @SRAZKVT
> i don't think bootstrapping and having a stable abi are an essential component of a healthy ecosystem. in particular not having a robust interoperability story can motivate people to reimplement a lot of existing software, hopefully while taking lessons learned to heart
rust doesn't have a stable abi across rust <-> rust modules/crates, which has nothing to do with makes does the opposite of what you say -- all it does is making rust-rust dynamic linking impossible, so people have to drop to the system abi for it, and/or make any sort of build cache invalid whenever you update the compiler@navi @whitequark @SRAZKVT Android dynamically links its Rust code. This does require rebuilding programs when their dependencies change, but for a closed system like Android that isn’t a problem.
