IRC channel logs
2014-04-16.log
back to list of logs
<civodul>yes, it's often better to just unset LD_LIBRARY_PATH <viric>did anyone benchmark the memory usage of guix? <ivanshmakov>What I do not understand is why bother with “bit-sameness” if one’s going to trust the binaries retrieved from the server anyway? <taylanub>ivanshmakov: isn't server-trust an orthogonal issue to package-integrity, so to say ? <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 <viric>(LRN@#gnunet advertised that on irc) <taylanub>Am I understanding it right that `guix pull' only installs the newest front-end guix script for the user running the pull command ? The guix daemon as well as other users are unaffected ? <taylanub>If so, two questions: 1) Why isn't it just a package itself ? 2) nitpick: Why is it installed under XDG_CONFIG_HOME ? (I think DATA would have been more appropriate?) <taylanub>ah, never mind, both questions answered: it *is* a package, and the CONFIG directory contains a link to it, which makes sense ("configuring" what Guix version the user uses) <mark_weaver>taylanub: 'guix' is a package, but that package is always the last tarball release. <mark_weaver>if you want anything fresher than that (e.g. security updates) then you need to use either 'guix pull' or use git and 'git pull'. <mark_weaver>I don't recommend using 'guix pull' at present, because last I checked the downloaded updates are not authenticated. <taylanub>mark_weaver: so 'guix pull' can result in my .config/guix/latest becoming an independent guix installation instead of a link to a package in the store ? <mark_weaver>hmm, I'll have to read the source code to answer that question. <mark_weaver>okay, indeed it is a symlink to a directory in the store, but that directory is simply an unpacked tarball that's downloaded from savannah. <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? <taylanub>hrm, what package has xinit, or do we have some xorg "metapackage" that will install all the common tools ? <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. <taylanub>I'll see if I can try it out without xinit <mark_weaver>taylanub: one problem you're likely to run into is that we don't yet have a mechanism in place to handle setuid binaries, and on most systems X probably still has to run as root. <mark_weaver>(I guess there has been work to lift that restriction, but I'm not sure of the current status) <mark_weaver>a display manager has to be run as root anyway, so there's no need for setuid binaries. <mark_weaver>but 'xinit' is normally run as an unprivileged user, and yet has to somehow arrange for the X server to be launched as root on many systems. <taylanub>I get "no screens found" .. giving up for now, guess it will indeed not run on real hardware yet <taylanub>hrm, currently getting "/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory" when trying to configure some things with Guix-installed build toolchain <mark_weaver>did you set the environment variables that were recommended by guix package -i ?