Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
AFAIK, nobody uses it, it's not maintained, and it has no tests.
|
|
|
|
On a system with multiple CPUs, running Nix operations through the
daemon is significantly slower than "direct" mode:
$ NIX_REMOTE= nix-instantiate '<nixos>' -A system
real 0m0.974s
user 0m0.875s
sys 0m0.088s
$ NIX_REMOTE=daemon nix-instantiate '<nixos>' -A system
real 0m2.118s
user 0m1.463s
sys 0m0.218s
The main reason seems to be that the client and the worker get moved
to a different CPU after every call to the worker. This patch adds a
hack to lock them to the same CPU. With this, the overhead of going
through the daemon is very small:
$ NIX_REMOTE=daemon nix-instantiate '<nixos>' -A system
real 0m1.074s
user 0m0.809s
sys 0m0.098s
|
|
|
|
|
|
if /nix/store is a read-only bind mount
/nix/store could be a read-only bind mount even if it is / in its own filesystem, so checking the 4th field in mountinfo is insufficient.
Signed-off-by: Shea Levy <shea@shealevy.com>
|
|
http://hydra.nixos.org/build/3661100
|
|
vfork() is just too weird. For instance, in this build:
http://hydra.nixos.org/build/3330487
the value fromHook.writeSide becomes corrupted in the parent, even
though the child only reads from it. At -O0 the problem goes away.
Probably the child is overriding some spilled temporary variable.
If I get bored I may implement using posix_spawn() instead.
|
|
Hopefully this reduces the chance of hitting ‘unable to fork: Cannot
allocate memory’ errors. vfork() is used for everything except
starting builders.
|
|
|
|
|
|
|
|
http://hydra.nixos.org/build/3031618
|
|
|
|
|
|
|
|
E.g. Darwin doesn't allow this.
|
|
Also use utimes() instead of utime() if lutimes() is not available.
|
|
|
|
XZ compresses significantly better than bzip2. Here are the
compression ratios and execution times (using 4 cores in parallel) on
my /var/run/current-system (3.1 GiB):
bzip2: total compressed size 849.56 MiB, 30.8% [2m08]
xz -6: total compressed size 641.84 MiB, 23.4% [6m53]
xz -7: total compressed size 621.82 MiB, 22.6% [7m19]
xz -8: total compressed size 599.33 MiB, 21.8% [7m18]
xz -9: total compressed size 588.18 MiB, 21.4% [7m40]
Note that compression takes much longer. More importantly, however,
decompression is much faster:
bzip2: 1m47.274s
xz -6: 0m55.446s
xz -7: 0m54.119s
xz -8: 0m52.388s
xz -9: 0m51.842s
The only downside to using -9 is that decompression takes a fair
amount (~65 MB) of memory.
|
|
Since the Perl bindings require shared libraries, this is required on
platforms such as Cygwin where we do a static build.
|
|
Nix needs SQLite's foreign key constraint feature, which was
introduced in 3.6.19. Without it, the database won't be cleaned up
correctly when paths are deleted. See
e.g. http://hydra.nixos.org/build/2494142.
|
|
|
|
http://hydra.nixos.org/build/2306540
|
|
Nix now requires SQLite and bzip2 to be pre-installed. SQLite is
detected using pkg-config. We required DBD::SQLite anyway, so
depending on SQLite is not a big problem.
The --with-bzip2, --with-openssl and --with-sqlite flags are gone.
|
|
I was bitten one time too many by Python modifying the Nix store by
creating *.pyc files when run as root. On Linux, we can prevent this
by setting the immutable bit on files and directories (as in ‘chattr
+i’). This isn't supported by all filesystems, so it's not an error
if setting the bit fails. The immutable bit is cleared by the garbage
collector before deleting a path. The only tricky aspect is in
optimiseStore(), since it's forbidden to create hard links to an
immutable file. Thus optimiseStore() temporarily clears the immutable
bit before creating the link.
|
|
|
|
scripts.
* Include the version and architecture in the -I flag so that there is
at least a chance that a Nix binary built for one Perl version will
run on another version.
|
|
|
|
* Refactor the nix-channel unpacker a bit.
|
|
|
|
broke building on Cygwin and Solaris.
|
|
will eat them.
|
|
|
|
uname reports amd64.
* Drop the FreeBSD version number, e.g. "i686-freebsd" instead of
"i686-freebsd8.2".
|
|
|
|
This should be more robust and also plays better with
cross-compilation---it uses the host name, instead of using the build
name.
|
|
intermittent problems are gone by now. WAL mode is preferrable
because it does way fewer fsyncs.
|
|
the Nix:: namespace.
|
|
bindings to be used in Nix's own Perl scripts.
The only downside is that Perl XS and Automake/libtool don't really
like each other, so building is a bit tricky.
|
|
|
|
|
|
|
|
|
|
|
|
location to DBI and DBD::SQLite can be passed with --with-dbi and
--with-dbd-sqlite.
|
|
little RAM. Even if the memory isn't actually used, it can cause
problems with the overcommit heuristics in the kernel. So use a VM
space of 25% of RAM, up to 384 MB.
|
|
|