unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Yasuaki Kudo <yasu@yasuaki.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Advantages over Nix?
Date: Tue, 27 Oct 2020 05:29:40 +0900	[thread overview]
Message-ID: <E40D8FD6-F3E3-4355-ADE0-8824123EA86D@yasuaki.com> (raw)
In-Reply-To: <CAJ3okZ3CXr3rv5m_YLdWfzxpxLMOugU6YAR=J=JfrG6qkZQ30g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

Hi!

I was in almost the situation a few months ago and I spent a few weeks trying both NixOS and Guix.

To me, Nix felt more like a 'minimum viable product' for a startup company - it works well but seems to suffer from its own success - practicality is given priority over engineering cleanliness.

Guix felt the opposite - package installations and upgrades felt way slower (it takes much longer to download, requires more frequent lengthy compilation) , not to mention that it is outright useless without proprietary packages augmented by nonguix, etc, if you happen to have critical hardware unsupported by LibreLinux, the kernel that has been stripped of proprietary code.

I am no expert in neither Nix nor Guix but toward the end of my analysis (I have since moved to another assignment), I thought Guix would be better for the company because of its superior design (I thought)

I watched this NixOS roadmap video https://youtu.be/8M6yvJC00J4 and thought it might be running into many issues that could be more easily addressed by Guix.   I think one thing that was discussed was that Nix cannot manipulate nested Nix expressions (in order to use Nix as a replacement for Make)

I don't know enough about Guix to see if it directly solves that problem but I thought the idea of using Scheme was precisely to avoid reinventing the wheel.

I think Guix packages are easier to understand (I compared package definitions of Guix and Nix) and Guix has a far better reference manual compared to Nix.   But I have not found a good introduction guide to Guix yet.   I was following https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html  but it was far from complete.  To be fair, https://nixos.org/guides/nix-pills/ has a lot of outdated information as well...

I wish I could be more precise but this is all I know and I appreciate your question!!!

Cheers,
Yasu

> On Oct 27, 2020, at 01:15, zimoun <zimon.toutoune@gmail.com> wrote:
> 
> Dear,
> 
>> On Mon, 26 Oct 2020 at 13:42, Taylan Kammer <taylan.kammer@gmail.com> wrote:
>> 
>>> On 26.10.2020 11:41, zimoun wrote:
>> 
>> I think pack -f docker is going to be the "killer feature" in this case.
>> 
>> Well, the following doesn't seem so complicated either actually:
>> 
>>   https://nix.dev/tutorials/building-and-running-docker-images.html
>> 
>> But I really like how 'guix pack' can generate a tarball just as well,
>> which could be deployed and tested anywhere...
>> 
>> I'll need to make a few more comparisons.
> 
> Do not miss the '--save-provenance' option. ;-)
> It saves the profile/manifest which can be used to rebuild one
> manifest.scm file.  You could be interested in [1].  I am running out
> of time, but the profile/manifest->manifest.scm converter could be
> nice to have. :-)
> 
> 1:<https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00221.html>
> 
> 
> All the best,
> simon
> 

[-- Attachment #2: Type: text/html, Size: 4667 bytes --]

  reply	other threads:[~2020-10-26 21:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26  7:42 Advantages over Nix? Taylan Kammer
2020-10-26  9:29 ` Jan Nieuwenhuizen
2020-10-26 11:36   ` Taylan Kammer
2020-10-26 23:39     ` Ludovic Courtès
2020-10-27 10:35       ` Pjotr Prins
2020-10-27 13:14         ` zimoun
2020-10-28  5:58           ` Pjotr Prins
2020-10-26 10:41 ` zimoun
2020-10-26 11:44   ` Pierre Neidhardt
2020-10-26 12:46     ` Taylan Kammer
2020-10-26 12:42   ` Taylan Kammer
2020-10-26 16:14     ` zimoun
2020-10-26 20:29       ` Yasuaki Kudo [this message]
2020-10-26 22:32 ` Ricardo Wurmus

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=E40D8FD6-F3E3-4355-ADE0-8824123EA86D@yasuaki.com \
    --to=yasu@yasuaki.com \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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).