<clever>
hask_bee_3: if you generate a .service file with nix, then the version will be locked in until you re-generate it, and the files will remain cached
<clever>
hask_bee_3: the version of postgress may change without warning, and its just slower
<clever>
mfiano: weird
<clever>
mfiano: and if you run env from the same place?
<clever>
mfiano: what is launching nix-shell?
<clever>
mfiano: try without --pure?
<clever>
ottidmes: also, grub works with both legacy and efi, while systemd-boot is efi only
<clever>
mfiano: so its getting set at a later point, probably when the shell goes interactive and chooses to source more config files
<clever>
mfiano: what about running env in that same script that did the echo?
<clever>
ottidmes: and it would just be less work to fix 1 thing in grub, then 5 things in systemd-boot
<clever>
ottidmes: yeah, but there are other things its also missing
<clever>
ottidmes: systemd-boot just lacks that option
<clever>
ottidmes: also, in nixos, there is an option to configure how many generations go into the grub config, so your /boot doesnt get bloated
<clever>
hask_bee_3: the .runner script isnt documented in any of the manuals
<clever>
hask_bee_3: it reuses the nixos startup scripts, in a portable way, so it works on any os
<clever>
ottidmes: and i know grub inside and out
<clever>
ottidmes: systemd-boot dosnt seem to have very many options, and ive always been anti-systemd :P
<clever>
ottidmes: nice
<clever>
lejonet: pass -curses to the bash script nix generated, or set virtualisation.graphics = false;
<clever>
gchristensen: do you still have that gist link handy?
<clever>
hask_bee_3: gchristensen actually did something just like that about 3 days ago
<clever>
ottidmes: ah, that sounds like something that should be fixed, grub is far better then systemd-boot
<clever>
lejonet: also, try using --fast, its likely a small bug that is misleading you
<clever>
lejonet: extraDisks is a bash variable, not a nix one
<clever>
ottidmes: the only special things i can think of right now are toString, import, and readFile
<clever>
ottidmes: yeah
<clever>
ottidmes: and next time you eval, it will read it again
<clever>
ottidmes: some nix functions like import can just read it without copying it into the store
<clever>
ottidmes: and inside a string, you need to "do ${./this}" to make it at the nix level
<clever>
ottidmes: but if you /dont/quote/it at the nix level, it gets copied into the store, and replaced with a storepath
<clever>
ottidmes: if you "/quote/a/path" it wont be copied, its just a string that gets passed to the program
<clever>
pie__: there is also the <nixpkgs> vs <unstable> difference
<clever>
lejonet: the build-vm variant lacks that backdoor
<clever>
lejonet: mostly, nixos adds a root shell on a special serial port, to backdoor the vm
<clever>
Mic92: and it detects such re-launching, and drops into a shell, rather then trying to re-test itself
<clever>
Mic92: i think the vm leaves a special script in its build dir, and if you -K the build, you can nix-shell into it or something, and re-launch the vm
<clever>
pie__: oops, i missed an import before <nixpkgs>
<clever>
mfiano: you want bashInteractive
<clever>
mfiano: 'bash' is that simpler bash
<clever>
mfiano: nix-shell uses a more light-weight build of bash that lacks a lot of options
<clever>
Guanin: its nearly 6pm, and i have slept since we last spoke
<clever>
src is just passed down, so it works on either
<clever>
pie__: generic-builder.nix then calls stdenv.mkDerivation, where overrideAttrs can inject its own changes
<clever>
pie__: overrideCabal changes the params passed to generic-builder.nix, so it can change haskell level things
<clever>
pie__: ah, overrideAttrs vs overrideCabal, i think the difference is which level it overrides at
<clever>
pie__: the fetchgit
<clever>
pie__: but if you just unpack it locally, you can use src = ./.; and then freely edit anything
<clever>
Guanin: yeah
<clever>
pie__: you would have to edit the rev and hash after every edit
<clever>
pie__: yep, but now you cant modify the src as easily
<clever>
mfiano: nix-shell --pure disables all of those things
<clever>
M1k3y: then use that to find the paths you want, and add a cp command to put them somewhere under $out
<clever>
as a start
<clever>
'';
<clever>
ls -ltrh
<clever>
M1k3y: id add postInstall = ''
<clever>
that generates a vi script that will land in $PATH, so sudo can find it
<clever>
''
<clever>
exec vim "$@"
<clever>
#!/bin/sh
<clever>
disasm: so you will want to do something like installing writeScriptBin "vi" ''
<clever>
disasm: aliases are handled by bash, and `sudo vi` doesnt check aliases
<clever>
M1k3y: ah, then the installPhase has to copy those files somewhere under $out, and it has to be patched to know where to look
<clever>
mfiano: i just started with vi over a decade ago, and now its just hard-wired into my brain
<clever>
mfiano: i never bothered learning the difference :P
<clever>
mfiano: i aliased vi to vim, even shorter!
<clever>
disasm: and in terms of vim plugins gaining root, root controls them fully, via vim.nix
<clever>
disasm: yeah, that can be fun
<clever>
M1k3y: set fetchSubmodules=true; inside the fetchFromGitHub
<clever>
alexteves: what is the difference between ghc and runghc?
<clever>
~/.vimrc just doesnt exist
<clever>
disasm: so i just sudo -i and run vim directly as root
<clever>
disasm: i use the vim.nix i linked above, so vim just always has the right config
<clever>
mfiano: ive heard that emacs also has special plugins, where it will internally call sudo on its own, to gain write access to things, maybe vim has such things?
<clever>
the quit requirement is a bit anoying, but the editor runs as the correct user
<clever>
mfiano: and when the editor QUITS, sudo will copy the file back
<clever>
mfiano: when you run "sudoedit /root/foo", sudo will copy the file to /tmp, then run $EDITOR without root
<clever>
mfiano: ah, you could just symlink those 2 nvim directories then, simple
<clever>
mfiano: maybe just make a simple .virmc that does #include /home/clever/.vimrc, and configure that 2nd one to be relative to itself, to find its neighbors?
<clever>
mfiano: are they mostly in a single directory?
<clever>
mfiano: you could also symlink the /root/.vimrc to the other one
<clever>
mfiano: oh, and there is also sudoedit
<clever>
mfiano: you can just drop that file into /etc/nixos/ and then add ./vim.nix to the imports list
<clever>
mfiano: this embeds the vim config into the vim binary
<clever>
mfiano: but the nixos option to enable gpg is dumb, and screws up horibly if you ssh into that system
<clever>
mfiano: yeah, thats anoying, and why i switched to gpg-agent
<clever>
sphalerite_: it wasnt even nixops managed to begin with either!
<clever>
sphalerite_: also, i just used `nixops deploy` to upgrade a nixos 16.03 (from nixos-unstable) machine to nixos 17.09, and it experienced minimal downtime
<clever>
sphalerite_: i saw similar in virtualbox
<clever>
sphalerite_: nice, ive never seen that on real hardware
<clever>
and the tweak i did above is now in place, my router has postgress again
<clever>
Feb 25 08:01:35 router systemd[1]: Started PostgreSQL Server.
<clever>
mfiano: this allows you to access toe nightly, beta, and stable channels
<clever>
also, nix makes it trivial to fix problems like this
<clever>
Feb 25 07:48:44 router postgresql-start[8288]: DETAIL: The data directory was initialized by PostgreSQL version 9.4, which is not compatible with this version 9.6.6.
<clever>
forgot that small detail
<clever>
in configuration.nix, it needs to be ${pkgs.rustc}
<clever>
and nix-shell -p haskell.packages.ghc822.ghc gives me 8.2.2
<clever>
as an example, nix-shell -p haskell.packages.ghc802.ghc gives me the 8.0.2 version
<clever>
nix-shell
<clever>
nope
<clever>
only programs installed via nix will work
<clever>
also, any ELF file you download will just break, /lib/ld-linux.so doesnt exist
<clever>
i have so many gists that i had to find a dedicated service that deals with finding your own gists, lol
<clever>
and /etc/profile sources set-environment
<clever>
environment.variables.A = "1"; deals with escaping and directly handling variables, and environment.extraInit bypasses that and just does raw strings again, both go into a special set-environment script
<clever>
and environment.loginShellInit
<clever>
programs.bash.shellInit also goes into /etc/profile
<clever>
environment.shellInit inserts raw strings into /etc/profile
<clever>
environment.interactiveShellInit just inserts raw strings into /etc/bashrc
<clever>
there are half a dozen ways of setting env variables in nixos
<clever>
and you can just edit hardware-configuration, just be aware that it gets overwritten, if you run nixos-generate-config by mistake
<clever>
but your free to just never use that again, and manage it all yourself
<clever>
mfiano: the only real point i see with hardware-configuration, is to make it easy to re-generate the basic mount stuff with nixos-generate-config