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