From: myglc2 <myglc2@gmail.com>
To: Alex Vestgaard <birkeroed@protonmail.ch>
Cc: "help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: GuixSD installation: binary vs source packages
Date: Fri, 24 Feb 2017 21:01:39 -0500 [thread overview]
Message-ID: <8660jzav0c.fsf@gmail.com> (raw)
In-Reply-To: <RKjslCs1toc6oiS8cLM8vVhDde45JQ2SLy6p2UrRZkWZQOqyELrSjri_PXeFlYa4HSJfz38Jri0uZHum8cSBDFQzqu__dxcQcV-a9MlucEY=@protonmail.ch> (Alex Vestgaard's message of "Fri, 24 Feb 2017 13:39:23 -0500")
On 02/24/2017 at 13:39 Alex Vestgaard writes:
> Hi,
>
> I'm trying to migrate all my machines to GuixSD, which I believe will
> make some complicated data processing pipelines much easier to deploy
> and reproduce.
>
> I have one question regarding the installation process, which other
> people on #guix could not answer. How can I determine what packages
> will be installed from source and compiled vs just binaries fetched
> from Hydra?
In my practical experience of running a GuixSD headless server for the
last 12 months, if you use 'guix pull', which is effectively a rolling
release, there is no way to tell. It depends on whether hydra has the
substitute you want, how responsive it is, the version you are
installing, etc.
I run Debian on an identical server, and the Debian updates typically
take 1/10th the time of a GuixSD update. And the Debian updates inspire
confidence in a way the GuixSD updates do not. This used to bother me,
but I got over it ;-)
I mostly use a Guix git source checkout and "re-"build guix from time to
time. I find, as far as my server goes, that I take a hit each time I
git pull and build Guix, and then the incremental installs of packages
are pretty quick. But I am doing this primarily because I am interested
in the Guix source and being able to patch guix packages, etc, not
because of update speed. If you don't care about the source, I think you
should probably use guix pull.
I have 3.4GHz, 8 CPUs and 30 MBPS internet and in practice my updates
don't take more than 5-10 min, whether I git pull and build from source
or guix pull, so it is not really a big deal in either case.
I am running a headless server, and not building a bunch of desktop
packages, which may make a difference in all this.
You can keep all of your machines on the same release by using a git
checkout, and share the store among them from a local server. This would
dramatically speed things up.
If you are using guix pull, it will again depend on whether substitutes
in your local cache is relevant.
> I tried the --dry-run for guix package -i and guix build, but I didn't
> find this very informative.
>
> Lengthy compilation took me by surprise twice:
>
> i) When I first started installing GuixSD, Guix got compiled. I
> expected a binary would be fetched instead.
The problem here, as I understand it, is that, by the time a Guix Noob
is using the install image the substitutes for that version of guix may
have "aged off" of hydra. I believe hydra's capacity has been improved
so this situation may be improved.
> ii) When installing icecat. I thought in principle there were binary
> substitutes for all packages in Hydra.
> I would appreciate if anyone could clarify these.
Let me just say that I have found GuixSD to be very solid. There are
occasional glitches with newly ported packages, which is to be
expected. Compared to Debian 8, and practically speaking, as daily
drivers, my GuixSD machine has slower updates and the GuixSD packages
are more up-to-date, which is more important to me. So I plan to switch
the Debian machine over to GuixSD.
HTH - George
next prev parent reply other threads:[~2017-02-25 2:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 18:39 GuixSD installation: binary vs source packages Alex Vestgaard
2017-02-25 2:01 ` myglc2 [this message]
2017-02-25 15:52 ` Leo Famulari
2017-02-25 20:12 ` myglc2
2017-02-26 3:23 ` Leo Famulari
2017-03-06 10:59 ` Ludovic Courtès
2017-03-06 16:09 ` dian_cecht
2017-03-07 10:59 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8660jzav0c.fsf@gmail.com \
--to=myglc2@gmail.com \
--cc=birkeroed@protonmail.ch \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).