<clever>
MichaelRaskin: that has been on my todo list
<clever>
MichaelRaskin: i would just patch the xorg modules in nixos to be able to run 2 at once
<clever>
gchristensen: and also a declarative hydra project could define /etc as a project input, and get a snapshot of your entire system config
<clever>
gchristensen: from what i understand, a "fixed-output" derivation can do whatever network it wants against any machine in the LAN, possibly the private ip of the host
<clever>
judson: and what that loads, depends on the contents of that default.nix (and by proxy, the all-packages.nix and nearly every file in nixpkgs)
<clever>
judson: nix-env -q will load the default.nix of every channel, and then eval it to get a set
<clever>
that could be mbr partitioning or legacy booting
<clever>
ahstro: efi vs legacy?, mbr vs gpt?, what rootfs type?, luks?
<clever>
ahstro: a few questions that affect the partitioning answer
<clever>
other then preferLocalBuild
<clever>
normally, nix-daemon helps, but its harder to tell the daemon to not use NIX_BUILD_HOOK
<clever>
and the store itself
<clever>
that just disables remote builds entirely (but changes the output hash)
<clever>
eqyiel[m]: you can also set preferLocalBuild = true; inside the derivation
<clever>
and without NIX_REMOTE, it cant cheat by using the local nix-daemon
<clever>
eqyiel[m]: without NIX_BUILD_HOOK, it will loose support for remote builders
<clever>
eqyiel[m]: if you have root, you can unset both NIX_REMOTE and NIX_BUILD_HOOK when you run nix-build
<clever>
joko: so i'm not sure when exactly the corruption is happening
<clever>
joko: its mostly blocked by nixos re-mounting /nix/store read-only, so not even root can do it
<clever>
joko: python has been pretty bad at corrupting storepaths, you need to run "nix-store --repair-path" on that first
<clever>
joko: /run/current-system
<clever>
there is also nixUnstable, but its ... unstable right now!
<clever>
only master!
<clever>
just below the commit msg, is a list of branches that include that commit
<clever>
so just changing the arch broke everything in the build
<clever>
and the old wowmapviewer devs had commited things like config.h that where generated by configure
<clever>
also, blizzard was constantly breaking wowmapviewer by changing the way map files are formatted
<clever>
couldnt figure out the vertex shaders
<clever>
i never got the 3d rendering side to work right
<clever>
which created the shadow
<clever>
each letter is 4 triangles, each pair forming a rect, to render the character twice, once in black, once in white, with an offset
<clever>
in this mode, it was rendering 2d triangles with textures
<clever>
my opengl stack wasnt tied into xorg at all, so it just ran fullscreen from the console
<clever>
sphalerite: bottom image is wowmapviewer running on a raspberry pi, with my custom driver stack (and the background color adjusted so i could confirm the shadow rendering worked)
<clever>
sphalerite: top image is wowmapviewer running on my laptop, with normal linux video drivers
<clever>
sphalerite: and it could also do add and multiply operations, in the same clock cycle, the opcode encodes 4 inputs, 2 outputs, and 2 operations (one each from the add, and mult sets)
<clever>
sphalerite: it was basicaly a 192 core processor, heavily geared towards running the same code in parallel on different datasets
<clever>
sphalerite: the 3d engine within the rpi
<clever>
sphalerite: i have written my own raspberry pi driver, from scratch
<clever>
depending on implementation
<clever>
but the linux side drivers may couple things more
<clever>
and you can just blast the 3d frames to anywhere in physical memory
<clever>
in the case of the rpi, the 3d core isnt really coupled to the 2d framebuffer logic
<clever>
tanonym: you will want to mount the <pool>/<fs> to /mnt/ before you mount boot
<clever>
tanonym: did you mount the pools root to /mnt/ before mounting boot?
<clever>
infinisil: grub has trouble traversing /nix/store/ and copyKernels puts them into a simpler directory structure
<clever>
infinisil, avn: but if you use copyKernels with /boot on the same FS as /, it will still copy it, and then grub doesnt have to deal with the insanity that is /nix/store/
<clever>
infinisil: i think zfs will just auto-generate a GPT partition table if you tell it to use the whole disk
<clever>
zfs also works on luks volumes, if you are not yet using the built-in zfs encryption
<clever>
tanonym: grub also doesnt play that nicely with zfs, so you may want a small /boot partition with ext4
<clever>
the target nixos will figure that out on its own, because there is an entry in hardware-configuration.nix mentioning zfsa
<clever>
tanonym: the host configuration.nix needs that to even be able to create a zfs on the "target"
<clever>
lol
<clever>
turning off glamor made 2d faster, and removed all 3d accel
<clever>
and it acted like a v-sync wait, after every printed character
<clever>
the bug only showed itself under xterm, other terminals lacked it
<clever>
which resulted in the old bug being present on nixos
<clever>
Unode: but the nixos scripts for generating xorg packages where not aware of that merging, and used the deprecated external glamor, that still had the problem
<clever>
Unode: in my case, glamor was a seperate repo, with that bug, then it got merged into xorg proper, then fixed
<clever>
Unode: my glamor problem was also fixed years ago
<clever>
Unode: i think i saw something similar happening 3 days ago, when i ran screen under tmux
<clever>
Unode: i recently ran into a problem, something hydra built is using SSE4, and my laptop lacks it
<clever>
Unode: yeah, my laptop needed legacy nvidia to even start
<clever>
Unode: but nixos handles this much better, because the resulting install is pure, and has no traces of the previous failed attempts, so i am free to try things and know it will have no lasting effect
<clever>
Unode: the open source drivers crash hard if i unplug the 2nd monitor while its active
<clever>
Unode: the closed-source ati drivers crash hard if i enable dual-monitor
<clever>
Unode: an older build of the opensource drivers uses the wrong version of glamor, which causes xterm to wait for vsync, after every printed character
<clever>
Unode: for example, one of the drivers will sometimes cause xorg to crash hard and stop, if i ssh in and restart xorg, the kernel hangs
<clever>
Unode: i have had weird problems with some of the driver choices, but nixos makes it trivial to remove all traces of failed attempts
<clever>
Unode: lol
<clever>
lol
<clever>
hl: yeah, once i get a system booting, i avoid touching things that low level
<clever>
tanonym: you can boot GPT drives on non-efi machines, if you create a "bios boot partition", 2mb, no FS, never mounted, and configure grub to continue booting via legacy
<clever>
tanonym: GPT with legacy needs a different special partition type
<clever>
tanonym: GPT with efi needs a special partition type and some vars setup in the bios by the installer
<clever>
tanonym: i was able to use just that copy of nix to install nixos ontop of gentoo, and get the system fully working
<clever>
tanonym: ive broken a gentoo install, by mv'ing nearly half the OS off the hdd, it still had an ancient copy of nix in /usr/local/bin/
<clever>
tanonym: :D
<clever>
tanonym: anything you manualy installed with nix-env -i wont be cloned
<clever>
tanonym: every copy of nixos has nixos-install, and can create more copies
<clever>
tanonym: you can also use the nixos running on the hdd to do the nixos-install
<clever>
yep
<clever>
tanonym: you will need to temporarily set the grub device to sdb to install the bootloader to the MBR, then change it to nodev
<clever>
tanonym: as long as grub can read the rootfs, yeah, you can just make a rootfs only
<clever>
Unode: only things built by nix and stored in /nix/store/ will continue to work in the future, anything you build and keep in $HOME and elsewhere are untracked and the GC will break them
<clever>
ma27: i think the problem is when building the haskell zlib wrapper, it fails to find the original c zlib headers
<clever>
Unode: so your always better off letting nix build things, using either cabal2nix or stack2nix
<clever>
Unode: anything you install with "stack install" is likely to break without warning in a month or 2, when nix garbage collects the libraries it was using
<clever>
Unode: there is also stack2nix
<clever>
Unode: what about just nix-env -iA nixos.haskellPackages.hoogle
<clever>
what if you run it under "nix-shell -p zlib" ?
<clever>
Unode: gcc wont look there, the setup hooks wont run right, and the propagated inputs wont be present
<clever>
Unode: why would you want to do that?
<clever>
tanonym: 341 to 399 generate the iso image
<clever>
tanonym: and line 291 mounts the iso to /iso
<clever>
tanonym: the same .ro-store and .rw-store stuff on line 301-318, but this time against /iso/nix-store.squashfs
<clever>
tanonym: 24 turns on efi, 27 makes the iso image also have an MBR partition table, and those options exist elsewhere (the files on lines 10-15)
<clever>
tanonym: so a writable compressed filesystem, like zfs, will win
<clever>
tanonym: and everything will be in the uncompressed writable layer
<clever>
tanonym: the issue though, is that when you do a major update and garbage collect, the read-only will become 90% garbage, that can never be deleted
<clever>
tanonym: but you could modify it, to union a writable and a read-only
<clever>
tanonym: all of the tmpfs based stuff in nixos, involves using a unionfs to merge a tmpfs and a squashfs
<clever>
tanonym: android does the same thing, the os lives on a read-only /system and the user stuff on a writable /data
<clever>
the non-persistant iso uses squashfs, which is read-only compression
<clever>
at the cost of more cpu usage
<clever>
gzip-9 can compress things pretty far
<clever>
tanonym: oh, using a filesystem like zfs that supports compression may help
<clever>
xfce or just raw text console
<clever>
i change it to "nodev"; after the install, so i cant mess with the 2nd sata drive by mistake
<clever>
just be careful, boot.loader.grub.device = "/dev/sdb"; wont always point to the usb stick
<clever>
you can also change configuration.nix and nixos-rebuild, and it will stick
<clever>
tanonym: yeah, a normal install to the usb stick will let everything persist
<clever>
tanonym: it will go into a tmpfs and be lost at shutdown/reboot