IRC channel logs


back to list of logs

<lfam> mark_weaver: I saw in the logs you said that the Guix packages are totally different from the Nix packages. I thought there was supposed to be some level of compatibility? The docs section 2.2 says they can share the store.
<mark_weaver>lfam: yes, they can share the same store
<mark_weaver>what I meant was that the actual set of packages that guix produces is completely different from the ones that exist on a Nix system.
<mark_weaver>the reason I bring this up is because it's not obvious what advantages there are two putting Nix and Guix is the same store
<mark_weaver>so, they might as well live in different stores, and be managed by different daemons.
<mark_weaver>so, I don't see why it's a problem for someone to have both /nix/store and /gnu/store on their system, if they want to run both systems together.
<lfam>Yes, if the packages themselves cannot be reused, it's not that useful.
<Mathnerd314>Nix could use Guix's packages. but that would be Guix supporting non-free software, I guess
<lfam>Although if you were running both on the same system, it's nice and simple to only have one daemon managing the store.
<lfam>Mathnerd314: I suppose, and that is a pretty important thing to this project, from what I have seen so far
<mark_weaver>Mathnerd314: Guix can be used on essentially any distro, including Nix. What's the problem?
<Mathnerd314>mark_weaver: well, currently effort is duplicated between Guix and Nixpkgs as far as maintaining GNU packages. but if Guix were compatible with Nix, then Nixpkgs could, at least in theory, just drop all of its GNU packages and just use Guix's
<mark_weaver>you still can
<mark_weaver>you can set the store prefix to be whatever you want when you compile guix.
<mark_weaver>it's an option to our 'configure' script
<mark_weaver>however, if you change the store prefix then our precompiled binaries won't work.
<mark_weaver>but the nix project obviously has the capacity to run its own build farm, and already does
<mark_weaver>however, our package descriptions, and the associated infrastructure to support those pacakges, are written in Guile Scheme. I guess the Nix project wouldn't want that, but if they want it they're welcome to it.
<mark_weaver>Mathnerd314: what I suspect you don't understand is that our store prefix is the most trivial and easiest to avoid incompatibility between Nix and Guix.
<mark_weaver>but that there are a vast number of other incompatibilities
<mark_weaver>the amount that Nix and Guix have in common is extremely little
<mark_weaver>it's like comparing Android to Debian. They have (mostly) the same kernel, but other than that it's all different.
<mark_weaver>in the case of Nix vs Guix, they have (mostly) the same daemon (for now), but other than that it's all different.
<mark_weaver>Mathnerd314: one more thing: if you really want to adapt our pre-compiled binaries for use in /nix/store, that's pretty easy to arrange, since "/nix/store" and "/gnu/store" are the same length. You could just rewrite all occurrences of "/gnu/store/<nix-hash>" to "/nix/store/<nix-hash>", similarly to what is done to support fast security updates of foundational libraries by rewriting references.
<zacts>hi guix
<moyamo>Hi, I noticed nix is post 1.0 and guix is still pre 1.0. Is nix more stable and feature complete than guix?
<rekado>moyamo: I have not used Nix before, but I do use Guix at work and privately.
<rekado>The system (GuixSD) is not yet as convenient as it should be, but it certainly is stable.
<rekado>The package manager (Guix) is extremely reliable.
<rekado>I use it to help a great number of users manage their scientific software on two clusters at the institute where I work.
<rekado>I don't know if it is wise to compare version numbers.
<moyamo>Is there a place where I can find a summary of the feature differences between guix and nix?
<moyamo>Besides Scheme vs Functional Langauge are there any other main differences.
<rekado>I don't know.
<rekado>BTW: we're using a functional subset of Scheme.
<moyamo>I probably should have said Haskellesque vs Scheme :)
<rekado>there are differences emerging from this design decision, e.g. that packages are code/data and Guix is really just a Scheme library that can be used with other applications needing package information.
<rekado>iyzsong: since the core-updates merge ibus-libpinyin no longer builds unless I explicitly add "glib" and "gtk+" to the inputs. Is this expected, e.g. after changing the glib-or-gtk-build-system?
<iyzsong>rekado: gtk+ is removed from the build-inputs of the glib-or-gtk-build-system (glib:bin is still there). I think packages better add gtk+ as input explictly, but for glib:bin, I don't have a strong idea.
<paroneayea>hello everyone!
<xentrac>that's cool
<xentrac>i like your thinking on how to make software freedom a practical reality
<xentrac>it seems much more promising than the urbit approach ;)
<xentrac>fwiw you can in fact back up sql database data simply by copying the database table files; the problem is doing so when they're in a consistent state
<xentrac>a lvm or filesystem that supports snapshots can solve this problem
<xentrac>netapp was using this as a selling point in 1996
<xentrac>you'd think it would be surprising that it's taken this long for the idea to catch on but for a long time they were going around threatening people with lawsuits
<paroneayea>xentrac: might filesystem with snapshots still snapshot a database where things aren't at a consistent state?
<paroneayea>eg if not all data is flushed, etc
<paroneayea>I thought that was part of the reason but maybe I'm wrong
<xentrac>if your database is buggy, that can happen
<xentrac>but traditionally databases are written with the intent of being able to recover from power failures
<xentrac>and that's sufficient to be able to recover from a snapshot backup
<xentrac>i mean basically you're traveling into a parallel universe where there was a power failure at the time of the snapshot and all the computation that happened after that never happened, because you shot its grandmother
<xentrac>does that make sense
<xentrac>the traditional problem with backing up databases without snapshots is that you back up different files at different times
<xentrac>so if you have records in table a and table b that are supposed to be in a one-to-one relationship, for example, whichever one you back up second may have experienced insertions and deletions not reflected in the state of the other one
<xentrac>a very common case of this is where 'table a' is actually a table and 'table b' is an index on it
<xentrac>it's okay to back up files that have data from uncommitted transactions in them, as long as you know the transactions are uncommitted; you would think you could solve this by backing up the transaction log file first, but that doesn't help
<xentrac>because by the time you get around to backing up a given table, the data that your transaction log was referring to may have already been overwritten by new transactions you haven't even heard of, and the old version thrown away because the database didn't know anybody was still that far behind
<xentrac>all these problems go away with snapshots
<xentrac>is that helpful, perhaps
<paroneayea>xentrac: will read / think about it in a bit!
<paroneayea>I have to run some errands
<paroneayea>thanks! :)
<_Raiz>what should I name the package defintion file @ the source directory?
<wgreenhouse>paroneayea, xentrac: your conversation is making me reconsider the ordering of my backups--I think I will now do btrfs readonly snapshot first and then duplicity/rdiff-backup from that :)