<clever>
and tell the build to look there when it needs to read things
<clever>
then just mkdir $out, and copy the source there before the build
<clever>
nixer: does the source need to be available after compile time?
<clever>
everything after that is within nixpkgs and the stdenv, and can do things in pretty much any order, as long as $out is valid at the end
<clever>
basicaly, all nix does is run your builder, with given args, and sets the $out variable
<clever>
and nix doesnt care when in the derivation you make it
<clever>
its the derivations job to create it
<clever>
and once the derivation has started building, $out is known
<clever>
and copy at the start of one, then use it later
<clever>
ditch one derivation entirely
<clever>
like preConfigure
<clever>
nixer: copy the src to $out/src before you build
<clever>
nixer: why is line 44 refering to the self derivation?
<clever>
yeah
<clever>
nixer: that just copied the propagatedNativeBuildInputs to the propagatedUserEnv, which i avoid using at all costs
<clever>
it appears to connect and "run"
<clever>
at line 760, i can see it connecting to X
<clever>
mpcsh: if you run "strace -ff -o logfile compton" it should produce a bunch of logs, can you run "gist -p logfiles*" to upload them all?
<clever>
turning gpu accel off made it faster
<clever>
that is the exact cause of my horid fps in xterm
<clever>
but nixpkgs isnt aware of that, and keeps building the out-dated foo, and the new bar without --enable-foo
<clever>
gchristensen: foo got merged into bar, and is now just --enable foo
<clever>
gchristensen: a secondary issue, is that the auto-generated thing pulled in deprecated packages
<clever>
i tried running the update script, and it just broke everything
<clever>
FRidh: there are also horid messes like the xorg packages, which have been heavily modified after the last auto-update
<clever>
both so people can reproduce the changes and confirm its not been tampered with, and so anybody can generate the next version
<clever>
something i have thought of, is to always include the commands you ran to generate in the commit message, along with any inputs needed to ensure its 100% reproducible
<clever>
and i havent gone back
<clever>
but when they updated, i ditched gnome and went all xfce
<clever>
i had been using gnome-panel since 2004, and was always graphing the cpu/memory usage
<clever>
i jumped ship when gnome turned into windows 10, lol
<clever>
past 7 9's, its hard to tell an outage apart from just pure latency
<clever>
but past 5, things get tricky
<clever>
seequ: i could measure a difference between 4 and 5 9's
<clever>
if i wanted to host something better then 2 9's, id need a beefy UPS or generator
<clever>
even my power company gets between 2 and 3 9's
<clever>
yeah, depends a lot on how many 9's you want
<clever>
yeah, aws shield, came out in december
<clever>
i was thinking in terms of using ELB to filterer a ddos
<clever>
copumpkin: ELB has a thruput limit and can be maxed out, and it takes time to spin up more ELB's
<clever>
now you can easily update 1 ip, without having to know the old IP your trying to overwrite
<clever>
and the RR is a single entity, that only changes when the list of targets changes, but not what IP they have
<clever>
then the EIP will always update 1 subdomain A
<clever>
domenkozar: you make the RR a list of aliases, pointing to subdomains with A records
<clever>
domenkozar: i also had an idea a while back on how to manage round-robin via nixops, rather then try to update the A records within the RR when an EIP changes
<clever>
latency based routing sounds more tricky
<clever>
geolocation based routing could be done entirely within bind, just define what subnets get what subset of the results, but yeah, that could be messy without a subnet to location db
<clever>
can bind even do those?
<clever>
but i havent messed with latency or geolocation based routing
<clever>
i usually manage the zone file directly, and then rebuild-switch
<clever>
simpson: the bigger problem i can forsee, is how do you give the user ssh access automatically, there needs to be a metadata service so you can auto-config on first boot
<clever>
that makes it imposible to run something like a full bitcoin node, without getting root and messing around with things
<clever>
and a 1.8 tb / partition
<clever>
simpson: and as an example of poor choices, one of my servers is now stuck with a 20gig /home partition that sits at 56% used
<clever>
simpson: my kexec trick lets you wipe the machine and do whatever you want
<clever>
simpson: so you have to start with an image that has an FS and layout you can accept
<clever>
simpson: as for the major differences between nixos-in-place and my kexec trick, nixos-in-place leaves you stuck with whatever partition layout the machine had to begin with
<clever>
dhess: that gist also includes bits of dhcp config, and a way to give every machine its own default