<clever>
thblt: which means you dont need a stable swap encryption, leading to swapDevices.*.randomEncryption
<clever>
thblt: so hibernation is out of the question if you have zfs
<clever>
thblt: the reason i was asking about FS earlier, is that zfs doesnt support suspend to ram, or disk
<clever>
ah
<clever>
srhb: i tried to run hydra-eval-jobs on btrfs a year ago, it had to create ~20,000 400 byte files in /nix/store, btrfs timed out on writing, and went into read-only mode
<clever>
so there are multiple copies of it
<clever>
and even that i think is a ring-buffer
<clever>
where it has to change some pointers into the immutable data
<clever>
the only mutable part is the root directory area
<clever>
but if snapshots are on, it will keep them around
<clever>
and if you have no snapshots, it will GC the old versions fairly quickly
<clever>
any time you write to the disk, it creates a new variant of the file (and every directory above it), refering to a combination of the unmodified blocks, and the new blocks
<clever>
nearly
<clever>
zfs is a bit like nix, all blocks on the disk are immutable
<clever>
ive been using zfs on most of my new installs
<clever>
that will play into these choices some
<clever>
thblt: also, what filesystem do you want for the rootfs?
<clever>
i havent done any testing to verify the speed, but its a decade old laptop, so its not likely to make a difference to me
<clever>
then the rootfs and swap live on lvm
<clever>
in my case, i only have a single luks, and then i ran pvcreate + vgcreate on the luks device, followed by 2 calls of lvcreate
<clever>
i just used LVM to do the same thing
<clever>
so you only enter 1 pw by hand, for that 3mb partition
<clever>
thblt`: he is using the 3mb partition as a "password", to unlock 2 more luks, the swap and rootfs
<clever>
thblt`: aha, i see why he did that
<clever>
i would just skip that
<clever>
weird
<clever>
thblt`: weird, can you link the guide?
<clever>
Infinisil: my dell with a half-dead battery gets ~40 minutes
<clever>
thblt: i think thats to let it boot without the user entering a pw, which sort of makes the luks pointless
<clever>
he often picks it up by the display, and my dells wouldnt last a week if i did that
<clever>
dash: taktoa has a laptop from there and i hear its pretty solid
<clever>
pierron: that sets things like createhome automatically
<clever>
pierron: and also, isNormalUser = true;
<clever>
pierron: yeah, thats why it fails horridly when you just symlink the root directory of this "overlay"
<clever>
timclassic: which is the one i mentioned
<clever>
timclassic: do any other files contain the word overlay?
<clever>
because <nixpkgs> loads the overlay, which loads <nixpkgs>, which loads the overlay ....
<clever>
but that can also cause infinite recursion if configured wrong
<clever>
default.nix will import <nixpkgs> and apply the overlay for you
<clever>
timclassic: you want rust-overlay.nix
<clever>
timclassic: that points to default.nix, which is not an overlay
<clever>
timclassic: what overlay did you symlink?
<clever>
and that was enough to make the list work in android
<clever>
the java core gave an api to query the row count, and to fetch a given row#
<clever>
it was an sqlite database
<clever>
and i just remembered, the chat history wasnt an in-ram array
<clever>
so i just had to give it a function to turn a single row into a UI element, and plug the 2 together
<clever>
and android has some powerfull tools to turn an array into a low-ram usage list on-screen
<clever>
chat for example was handled almost entirely in core, which kept arrays of history for each channel
<clever>
the ui was then just a matter of calling the right rpc methods (via the wrappers), gathering values, and presenting them
<clever>
deltasquared: the java core was 80% wrapping the http based RPC in java functions, and 10% tracking state via polling for events
<clever>
deltasquared: both of those shared the java core, so there was a lot less rewriting going on, and i could test the java core by just writing simple desktop based bots for the game, then quickly throw an android UI over it
<clever>
you need to find the driver source, and build thru via nix
<clever>
but even then, they cant load
<clever>
yeah, i see, it tries to modprobe the drivers, and if that fails, it tries to build the drivers
<clever>
same general set of files, no trace of any source that could use linux headers
<clever>
evangeline: i'm seeing files under /etc/vmware-installer, /usr/lib/vmware and /usr/lib/vmware-installer
<clever>
if your using find, thats -mount
<clever>
should also limit it from entering /proc and /sys
<clever>
and try uploading to gist this time, gist -p ccc.txt
<clever>
otherwise, the order will cause a false difference
<clever>
you may want to sort aaa and bbb before you diff them
<clever>
these look like false positives?
<clever>
+Wed May 20 05:10:20 2015 /bin/bzip2recover
<clever>
i dont see that helping that much
<clever>
they made this as un-friendly as they could possibly make it
<clever>
that elf helper then re-opens the bundle, and extracts moar!!
<clever>
all it can do is extract an elf helper
<clever>
evangeline: ah, i see my problem, this bash script is just unable to extract everything
<clever>
and it still only extracts 25mb, lol
<clever>
evangeline: edit the bundle, in replace mode (not insert mode!) and put an exit; on the 2 rm's in on_exit, and the install at the botton of main()
<clever>
vim silently added a single \n to the end of the binary content
<clever>
aha, thats why vim broke everything
<clever>
evangeline: it even contains iso files for vista, lol
<clever>
225018118 0xD698106 gzip compressed data, maximum compression, has original file name: "winPreVista.iso", from Unix, last modified: Mon Jun 19 23:57:36 2017
<clever>
evangeline: do you see a file like this anywhere in your docker?
<clever>
68359398 0x41314E6 gzip compressed data, maximum compression, has original file name: "vmnet.tar", from Unix, last modified: Mon Jun 19 23:54:39 2017
<clever>
19951200 0x1306E60 Windows Script Encoded Data (screnc.exe)
<clever>
evangeline: if i run binwalk over the bundle, i can even see windows executables!!!
<clever>
and the tar unpack is failing after 39mb, the tar is 456mb!
<clever>
evangeline: the tar i am able to extract contains no source code, and makes no mention anywhere of kernel headers
<clever>
there is no nix enforcing where it can make a mess
<clever>
and due to the FHS, finding what it modified is just a matter of guesswork
<clever>
we need to look at the files vmware added to the system
<clever>
evangeline: nearly all of those are unrelated to vmware, and those samples/examples arent required to make it work
<clever>
"output88 output89 output9000 output9001", nope, bash failed to re-assemble the split!
<clever>
evangeline: any .c files
<clever>
evangeline: even if you can get the kernel module to build, docker will never let you load it
<clever>
evangeline: to confirm if its a kernel module or a userland component
<clever>
then you can eval texlive within that repl
<clever>
kainospur[m]: like nix-repl '<nixpkgs>'
<clever>
kainospur[m]: you must give it the path to a file with nix expressions
<clever>
evangeline: so with the unmodified bundle, the above split command cuts it up, and outputaa contains the bash script, the rest are fragments of a tar.gz
<clever>
kainospur[m]: nix-repl '<nixpkgs>' then use tab completion
<clever>
kainospur[m]: userland components are far less fussy about what version of the kernel headers are used
<clever>
evangeline: i can confirm why the normal install fails, its expecting an ld.so at /lib64/ld-linux-x86-64.so.2, as it usual with ELF's from outside of nix
<clever>
ah, needs an obs also
<clever>
though its missing the last 15kb
<clever>
evangeline: i now have a normal tar file that i can just unpack
<clever>
evangeline: are you trying to get the vmware-workstation?
<clever>
evangeline: and reading the bash code, it has a --extract option
<clever>
evangeline: the bundle is just a bash script, prefixed to what is probably a tarball
<clever>
and i cant download until i register, lol
<clever>
it must have source, thats the only way it can use kernel headers
<clever>
evangeline: can you link the dl you used?
<clever>
evangeline: and where did you get this source from?
<clever>
it prefers .hi files over .hs!
<clever>
vim does the same thing, and cyces in a weird order, so i often open the wrong files
<clever>
evangeline: what part of vmware needs the linuxHeaders, can you pastebin the error?
<clever>
what are you building that needs the linux headers
<clever>
evangeline: is this the headers for building a module or a userland component?
<clever>
ah yeah, 4.9 is missing, let me see
<clever>
evangeline: also, to build a kernel module, you must use nix-build via the linuxPackages tree, nixos will fight you at every step if you try to build it by hand
<clever>
evangeline: and to answer your other question, linuxHeaders_4_9
<clever>
yeah, the nix-build also fetches it as well
<clever>
and my qemu/xen changes, are having trouble going from 16bit to 64bit mode
<clever>
qemu has a gdb server, but the gdb as a client, gets rather upset when you switch between 16bit, 32bit, and 64bit modes, so its difficult to debug early boot stuff
<clever>
what i'm doing is 100% self-contained to qemu, and can even be ran without root and kvm
<clever>
so you need a real xen hypervisor to use that
<clever>
and then qemu emulates the motherboard
<clever>
xen emulates the cpu, and will proxy all IO requests to a cpu-less qemu
<clever>
there is xen support in qemu, but its radically different
<clever>
so xen-only guests can run under qemu
<clever>
that emulates a xen hypervisor
<clever>
ive also modified qemu some, adding support for a custom x86 platform
<clever>
and acording to #osdev, bochs has a better debugger then qemu
<clever>
evangeline: i have heard in #osdev that bochs has a powerfull built-in debugger
<clever>
evangeline: how different is virtualbox from vmware?
<clever>
so its recomended to just use the package in nixpkgs if it exists
<clever>
evangeline: everything you download must be patched by a nix expression, or it will fail like that
<clever>
i'm not sure how its doing it
<clever>
ive also noticed how nix-shell will download the docs for the bash in the stdenv
<clever>
nixos-install is just a script that runs nixos-rebuild under a chroot
<clever>
and as always, you can just boot the installer, re-mount the root and /boot to /mnt and /mnt/boot, and run nixos-install to repair it
<clever>
i think it was reformat /boot, "nixos-rebuild test" with the right uuid, and systemd will mount the right thing, then "nixos-rebuild boot" to update /boot
<clever>
seequ: nixos can still be fixed
<clever>
so you cant mount the right one (because systemd'd uid is wrong)