<clever>
simp__: what happens when you hit the printscreen key?
<clever>
simp__: can you screenshot the page your looking at?
<clever>
simp__: it should be called bios_grub
<clever>
i had to disable efi entirely to make it stop
<clever>
simp__: i did also have issues where the bios 100% ignored the boot order i set, and always booted the efi windows
<clever>
simp__: simpler/faster to just unplug that hdd
<clever>
dcz: yeah, this cimg package is a bit of a mess
<clever>
simp__: i feel efi is optional, and i have never gotten it to work on any machine
<clever>
dcz: ah, i see why i cant override cimg, the author didnt make the package very well
<clever>
simp__: oh, and set boot.loader.grub.device = "/dev/sda"; (using the path for the hdd)
<clever>
simp__: after you change the type, mount root to /mnt, /boot is no longer required, re-run nixos-generate-config --root /mnt ; nixos-install
<clever>
simp__: it would be a bit of a waste of space, but you can change /boot into a bios boot partition (the bios_grub flag in gparted), and then switch to non-efi booting
<clever>
simp__: what filesystem did you use for / and how big is /boot?
<clever>
you also need to boot via efi to even see the efi config
<clever>
ah
<clever>
simp__: can you pastebin the output of "mount" ?
<clever>
simp__: and you ran that as root?
<clever>
simp__: efi is weird like that
<clever>
simp__: you need to boot the usb via efi if you want to be able to install an efi os
<clever>
id say its a bug with the cimg package then, one min
<clever>
ah
<clever>
i think you also need to use #include <cimg/CImg.h>
<clever>
you must put a package with those headers into the buildInputs
<clever>
dcz: the gcc in nix is modified to never look in /usr/include/
<clever>
simp__: and then pastebin the output of running "efibootmgr"
<clever>
simp__: can you boot from the usb again?
<clever>
simp__: let me double-check this end
<clever>
dcz: that will modify the stdenv to just use gcc5 by default
<clever>
and you can use a proper browser to look things up
<clever>
graphical is usualy better, gparted is just so much simpler then cli
<clever>
more easily accessed if your on the non-graphical iso
<clever>
there is also a nixos manual and a rogue game on alt+f8 and alt+f9
<clever>
:D
<clever>
simp__: spammers defacing everything
<clever>
simp__: about 2 years, and i dont see myself ever using another distro
<clever>
i have nixos on my laptop, desktop, router, nas, 2 netbooks, and 2 servers
2017-04-23
<clever>
yep :)
<clever>
its almost a dynamic dns layer running over ipfs
<clever>
so if i have your pubkey, i can find your ip, at any time
<clever>
you have a persistant keypair, and the (public key, public ip) is advertised on the dht
<clever>
and there are some minor privacy issues in how ipfs handles its p2p stuff as well
<clever>
ryantrinkle: so if somebody finds an exploit in /nix/store/foo, they can just ask IPFS, "who can give me a copy of foo?", and now they have a list of target IP's
<clever>
ryantrinkle: a second issue though, is that you are broadcasting to the world that you have a given storepath in your hdd
<clever>
ryantrinkle: so only cache.nixos.org-1 can be shared
<clever>
ryantrinkle: yeah, you could also have a whitelist for keypairs you can share
<clever>
hodapp: but things in foo's propagatedBuildInputs will propagate into bar's inputs
<clever>
ryantrinkle: but if the signatures are kept, you could just configure it to never share unsigned things, so the locally built stuff remains private
<clever>
for one, you would be able to download a complete copy of my nixos build, including its configs, just because i "leaked" the above path
<clever>
there are also some security issues i have heard about, if you start sharing the entire /nix/store over IPFS
<clever>
or just go nuts and throw in a hardware signing token
<clever>
and if your local builds where signed with a given pair, and you securely destroyed the secret, you can proove those are also unmodified
<clever>
and massively cut down on what you need to audit
<clever>
you could proove that 98% of the storepaths are unmodified originals from cache.nixos.org
<clever>
and it would make nix-store --verify --check-contents crypographicaly secure
<clever>
so even if an attacker gets root, and can mess with db.sqlite, he cant repair signatures on a year-old storepath
<clever>
and if you throw in some keypair rotation, and put a timestamp into the signature, you could proove what month something was signed during
<clever>
this also opens up the option of signing local builds when the build finishes, rather then when somebody asks for it
<clever>
ryantrinkle: without that, non-primary hydras have to re-sign everything they share, even if it was originaly signed by the main hydra
<clever>
ryantrinkle: oh, another thing ive been thinking of adding to nix, have it save the binary cache signatures to /nix/var/nix/db/db.sqlite
<clever>
bennofs: and at that point, fusenar can index the file, and cache that
<clever>
bennofs: and nix itself would need to be patched, so when you tell nix to substitute a .nar from the cache, it will save it to a dir and IPC fusenar, rather then unpacking
<clever>
bennofs: i think if i was to improve it now, i would have it index the .nar when you register it into the framework, and cache that in a db
<clever>
bennofs: haskell just turns half of the parsing job into a thunk, and can resume the parsing later
<clever>
bennofs: yep, but the type of the root node (file, or directory) required parsing the nar, and making a lazy parser in c++ had a higher difficulty then just redoing it all in haskell
<clever>
bennofs: i think it kept them as <hash>-<name>.nar i believe
<clever>
ryantrinkle: nope
<clever>
bennofs: 2, both have clever in the name, taktoa was just helping more with that project
<clever>
ryantrinkle: i still think perf could be improved more by keeping a database with the results of parsing things
<clever>
ryantrinkle: and just doing "ls /nix/store" led to it having to fully parse every nar in the entire store
<clever>
ryantrinkle: i had originaly written it in c++, but ran into performance issues because it had to parse the entire NAR (potentialy several gig) just to figure out if it was a file or a directory
<clever>
MichaelRaskin: and maybe systemd wasnt coded to handle errors when the carpet gets pulled out from under its feet
<clever>
MichaelRaskin: i think systemd glitched because the fuse app segfaulted, and the fs still existed
<clever>
and thats the host pid1, that was supposed to be spawning a container
<clever>
ryantrinkle: you are then unable to shutdown or reboot
<clever>
ryantrinkle: i also quickly discovered, that if the fuse program crashes in a weird way, pid 1 will get stuck at 100% cpu and go unresponsive
<clever>
just dont unpack the nar's!
<clever>
ryantrinkle: why not use fuse to mount a pile of .nar files at /nix/store?
<clever>
ryantrinkle: the idea with that project, is that ipfs needs a copy of the objects its sharing, and if you want to share your nix store over ipfs, you wind up with a copy in /nix/store, and a .nar file of equal size
<clever>
ryantrinkle: when i was experimenting with containers to test some fuse stuff, i had to run systemd-nspawn as root, but i was able to just put the rootfs anywhere
<clever>
usually better to just block the auto-update, and just update nixpkgs often
<clever>
(though steam has special stuff to handle it)
<clever>
in that case, the new version will fail to run
<clever>
though some things like steam and dropbox try to save the updates to a dir under $HOME
<clever>
GLn: the directory its installed to is read-only, so it will usualy fail to update
<clever>
like it forced a fetchurl derivation to be cross-compiled with the arm curl
<clever>
sounds more like a bug in the cross-compile framework now?
<clever>
though network should be disabled everywhere but a few well-maintained derivations
<clever>
bbl
<clever>
m3tti: you just need to enter a known-wrong hash
<clever>
m3tti: nix-build will tell you the correct hash when the hash fails
<clever>
m3tti: it will basicaly nix-store --dump the $out path, and hash that
<clever>
m3tti: nix needs the hash of the NAR (nix archive), not the hash of the .tar.bz2
<clever>
54% when visible, 40% when on another tab, no effect from minimizing
<clever>
though it would help massively if nix-build foo.nix would do it more like this by default
<clever>
joepie91: learning how import, callPackage, and function definitions work, would explain that issue
<clever>
joepie91: and how they where not compatible
<clever>
joepie91: when i was new to nix, i was often confused by packages needing either { stdenv, dep1, dep2, dep3 }: or with import <nixpkgs> {};
<clever>
and there is also the differences between pure nix, and nixpkgs
<clever>
sphalerite: the ONLY time a virus has ever gotten into a linux machine i run, is when i ran an outdated copy of exim, with a known exploit right in the irc channel topic, lol
<clever>
ToxicFrog: and the narinfo has the url to the .nar.xz (which may not be xz)