<taylanub>ivanshmakov: from my understanding, Nix/Guix type of packages give a certain guarantee about their content via the hash, which can be verified by manually rebuilding the package from its description ("expression"); in other words there's exact source->binary correspondance, so less things to worry about. in contrast, when one receives a traditional package (deb, rpm, pacman, w/e), it's not easy to determine how *exac
<taylanub>was built, one can get the same version and apply the same patches and try to use the same compiler version and flags and static libraries etc. etc. but it'll be difficult to get a bit-same package so one can know "ok, this package really contains no more than that version+patches"
<taylanub>someone else might be able to explain better, maybe check Nix and/or Guix documentation :)
<ivanshmakov>taylanub: The question is: why bother? If you’re going to trust the party that provides you with the packages, why trying to re-build them and checking if they’re the same? And if you don’t, – just follow the Gentoo way.
<taylanub>ivanshmakov: with "provides you with the packages" do you mean the expressions of the packages ? those are simple/short declarative documents which make it obvious that the resulting binary package will be uncompromised (as long as the upstream sources it references, and building toolchain, are trusted as well; it removes the middlepoint of places to worry about)
<ivanshmakov>taylanub: That’s the point: the party you get the packages from may have its build system compromised. As in: deliberately.
<taylanub>you can fetch the sources of the build system they claim to be using, and build the whole chain of packages yourself, then compare the hashes
<ivanshmakov>taylanub: Yes, but the fact that the digests match for one given package doesn’t mean that they’d do for the rest.
<YoungFrog>so verified > verifiable, but still: verifiable > nothing
<taylanub>sounds right .. for every "endpoint" whose hash you compare, you'll have verified the chain of packages from the "roots" to that endpoint; you would need to verify several endpoints you care about ..
<taylanub>several parties could set up independent build farms, and their hashes would all match, unless one is compromised and sticks out
<ivanshmakov>taylanub: Do you mean that the libraries’ digests are included in the message the package’s digest is computed upon?
<taylanub>ivanshmakov: all "inputs" to a build; that'd be static libs if I'm not mistaken
<ivanshmakov>taylanub: Then the shared objects may still not be checked.
<taylanub>the dynamic libraries will (hopefully) also be nix/guix packages that can be verified themselves. but I really hope someone who has a better understanding of nix/guix would chime in and verify/correct what I'm explaining :\\
<ivanshmakov>So, I’d summarize my understanding of that: Guix offers superior security by allowing the user to compare (as in: matches or not) the builds produced by independent third parties.
<ivanshmakov>As long as there /are/ such parties, that is. I don’t know if it’s really a major advantage, but certainly a feature that may come handy. So let’s see if such parties will indeed appear…
<viric>the gnu gsoc ml seems to have questions for guix people
<mark_weaver>to answer the question "Why isn't it just a package itself ?", if it was a normal package, and you started from a tarball release of guix, then how would you get a newer version of it than the guix tarball itself?
<mark_weaver>if you could get a newer version of 'guix' package, then presumably you could also get newer versions of other packages.
<mark_weaver>FWIW, I've never used 'guix pull'. I think it's aimed at end users who don't plan to modify guix or contribute to it. for those who intend to modify it or contribute, it makes a lot more sense to build guix from a git checkout, pull changes from the upstream repo, and either rebase your local changes on the latest upstream or merge upstream into your branch.
<taylanub>hrm, when I run multiple 'guix package' "transactions" in parallel, one of them wins and the others are lost ?
<taylanub>(or something else weird happened, a couple packages I could swear I installed don't seem to be installed)
<taylanub>they seem to be in the store though, so I think that's probably what happened
<mark_weaver>taylanub: that's right, 'guix package' assumes that you'll only have one instance of it modifying a given profile at a given time.
<mark_weaver>nothing terrible will happen if you run it more than once concurrently, but some of the changes will effectively not be made to your profile.
<mark_weaver>here's what happens: 'guix package' reads the manifest from the current profile, then makes changes to it, does the necessary builds including building a new profile, and then atomically changes the symlink to point to the new profile.
<mark_weaver>so basically, the last 'guix package' that changes the symlink "wins", and it might have based that on an older profile that doesn't include some of the changes made by concurrently-running 'guix package' commands on the same profile. does that make sense?
<mark_weaver>I know that Ludovic uses the 'slim' display manager as a way of starting an X session within the demo VM images.
<mark_weaver>I use 100% guix programs within my X session, but I still use an X server and xinit from my host (home-built) system. but then, I'm on a YeeLoong, where the standard upstream X server doesn't work anyway.
<mark_weaver>I vaguely recall that our X server may not yet be usable of most "real" hardware (as opposed to VM), but I'm not sure.