unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nils Gillmann <ng0@n0.is>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: You say nix, I say guix: Nix 2.0 and Guix
Date: Sun, 29 Apr 2018 17:44:06 +0000	[thread overview]
Message-ID: <20180429174406.lwz4syjt6uzrw64b@abyayala> (raw)
In-Reply-To: <87d0yjkrv2.fsf@gmail.com>

Chris Marusich transcribed 1.4K bytes:
> Hi,
> 
> On February 22nd, Nix 2.0 was released:
> 
> https://nixos.org/nix/manual/#ssec-relnotes-2.0
> 
> It contains a lot of interesting new features.  Are there any plans to
> merge some of the nix-daemon changes into our guix-daemon?  Is
> compatibility with the nix-daemon a goal of the Guix project?  Can we
> take inspiration from any of the non-daemon features and use them in
> Guix?  Conversely, is there anything we can upstream to Nix that they
> might find useful?
> 
> -- 
> Chris


What could be reused in my opinion, from the changelog and not simply code:

* Silent builds / operations by default.
  We already have the option for this, without the progress report iirc.
  Since only developers and Build machines are interested in the verbose
  building output, we could adjust the defaults to this?

* specific example in the --help output of the functions?
  At the moment we have generic examples. Something that tells
  people how to install for example libreoffice is much closer
  to their reality when they are lost (judging from my group of
  friends who are technically skilled but still not Guix current
  user group.).

* nix why-depends, nix path-info are nice.

* do we have a progress report on guix gc operations for optimizing?

* nix ls-store and nix ls-nar look interesting.

* "In Linux sandbox builds, we now use /build instead of /tmp as the temporary build directory. This fixes potential security problems when a build accidentally stores its TMPDIR in some security-sensitive place, such as an RPATH."
  This is a very interesting development. I wanted to move TMPDIR for specific cases anyway
  but did not consider yet another directory in the root. I would've used another location.

      parent reply	other threads:[~2018-04-29 17:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-28 20:17 You say nix, I say guix: Nix 2.0 and Guix Chris Marusich
2018-04-29 17:34 ` Ludovic Courtès
2018-04-29 17:54   ` Mark H Weaver
2018-04-29 17:44 ` Nils Gillmann [this message]

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=20180429174406.lwz4syjt6uzrw64b@abyayala \
    --to=ng0@n0.is \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).