ninjin has quit [Remote host closed the connection]
ninjin has joined #nixos-chat
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 264 seconds]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 268 seconds]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-chat
steveeJ has quit [Ping timeout: 240 seconds]
steveeJ has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
endformationage has quit [Ping timeout: 268 seconds]
__monty__ has joined #nixos-chat
<joepie91>
clever: hey, you work at IOHK, right?
<sphalerite>
joepie91: I believe he does, as does disasm
<joepie91>
ah, right :P
<joepie91>
clever: in that case, mind if I PM you about something?
<joepie91>
re: IOHK
<joepie91>
sphalerite: (thanks)
<joepie91>
(cuts out a back-and-forth iteration :P)
<clever>
joepie91: sure
<__monty__>
Hey, we're *all* interested in IOHK operating procedure secrets.
<gchristensen>
it is all OSS, you might find few secrets
<joepie91>
haha
<__monty__>
gchristensen: Yeah, right. Like I'll read all the nuances the way clever probably can.
<gchristensen>
haha, yes, that is very true
* tilpner
did zfs add instead of attach
<tilpner>
Guess that's what I'm doing with my sunday
<joepie91>
tilpner: what's that do?
<tilpner>
It adds a device for striping instead of mirroring
<tilpner>
Which means I now have to copy a total of 8TB back and forth onto scary old disks
<joepie91>
:(
<tilpner>
Nothing was written to the new drive, and yet zpool won't let me remove it
<tilpner>
Phew, unstable filesystem features saved my day
<tilpner>
0.8 can remove vdevs from a stripe with feature@device_removal=enabled
<ar>
tilpner: it does that in a funky way
<tilpner>
ar: What do you mean?
<ar>
tilpner: it, iirc, creates a hidden vdev that it prevents from landing on device-to-remove, and it replaces the device-to-remove with that hidden vdev
<tilpner>
Huh, what storage would that hidden vdev be backed by?
<ar>
tilpner: all the other vdevs in pool
<ar>
(other than "device-to-remove")
<tilpner>
Does that mean my pool now has a hidden vdev, or was that cleaned up after the removal finished?
<ar>
don't remember that part
<ar>
i'd expect man zpool to say more about it
<tilpner>
No, it doesn't really go into detail about how it performs the evacuation
<tilpner>
But that's okay for now, I'm happy I don't have to spend the rest of the day fixing this
<ar>
tilpner: just asked a friend of mine, and he thinks (he's not sure too) there isn't anything that would actively drain the hidden vdev, but it's also going to get new (created after starting removal action) data written to it
<ar>
so, if your data changes, your hidden vdev would get drained and removed over time
<tilpner>
Did you forget a "not" in there?
<tilpner>
"but it's also (not?) going to get new"
<ar>
right, i ate a word there
<joepie91>
om nom nom
endformationage has joined #nixos-chat
<ninjin>
Crivens, I thought I would look at what the world has brought in terms system monitoring since Munin. Turns out everyone and their dog made a tool and I am tempted to just roll Munin to get rid of the angst caused by all the choice. Bosun looked sensible though, a bit *NIX-y and modular…
jD91mZM2 has quit [Remote host closed the connection]
<eyJhb>
Really wish we could ignore some licenses, e.g. so I don't have to rebuild Virtualbox ALL the time.....
jD91mZM2 has joined #nixos-chat
<sphalerite>
eyJhb: blame oracle and stop using virtualbox? :D
<eyJhb>
sphalerite: what would you alternative be, VMware? :p
<eyJhb>
I actually just need VBox to pack a image so taht I can upload it to DO........
<sphalerite>
qemu
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 252 seconds]
<andi->
qemu-img can import/export to vbox just fie
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 240 seconds]
jtojnar has quit [Remote host closed the connection]
<elvishjerricco>
ar, tilpner: Yea I wish zfs scrub would remove the hidden vdev but I don't think it does
_Geeko_ has joined #nixos-chat
<_Geeko_>
hi guys!
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-chat
<colemickens>
kvm > vbox
<colemickens>
packer or Nix alone can make an image for DO tho?
<eyJhb>
colemickens: packer requires VBox or something like that, to make a image, if you aren't going to base it on top of the exisiting ones at DO
<colemickens>
Right, tt can use qemu/kvm too though
<eyJhb>
Possibly! Now my biggest problem is that it is trying to write output to /run/user/1000, which doesn't have enough space...
<tilpner>
gchristensen: How did you do the flamegraphs? Have a neat script you can share?
<joepie91>
that moment when you discover that DHL has a nice GraphQL API: https://track-and-trace.dhlparcel.nl/graphql?query=query{__schema{types{name}}} -- and that there's a little Docs button that gives you all the details lol
<joepie91>
probably not meant for third-party consumption but hey!
<joepie91>
planning on making a nice little status display
<joepie91>
might add parcel tracking to it
* colemickens
another thread about Azure, another thread with 100% comments trashing it
<MichaelRaskin>
OK, I give up my idea of not having Nix on the VPS because evaluation will eat entire 1GiB RAM, let it be just Nix for receiving side of nix copy
<colemickens>
has there been a chat about config languages here lately?
<colemickens>
curious what everyone likes instead of yaml/toml/nix
<colemickens>
hcl2?
<tilpner>
dhall is mentioned often
<__monty__>
dhall++
<infinisil>
colemickens: Yaml is bad because of the complicated spec; nix is bad because it allows executing stuff, only has a C++ API and no good standard library (you need the huge nixpkgs for that..)
* colemickens
nods
<infinisil>
So toml or dhall sound the best to me
<elvishjerricco>
Never really understood the argument against turing complete config languages. fix is an asset to e.g. the nixos module system, and languages like dhall don't prevent programs that will take ridiculously long to run.
<infinisil>
But if your program is exclusively used by NixOS people, then writing a NixOS module for option type checking and such, then converting to json to pass it to the executable, sound better
<elvishjerricco>
sure
<__monty__>
Do you *really* need general recursion though?
<__monty__>
Writing something that takes ridiculously long to evaluate in dhall is possible in theory but doesn't happen in practice. It's rarer than accidentally creating an infinite recursion.
<infinisil>
configuration languages should probably focus on more important aspects, like how easy it is to write, how good the error reporting is, whether you can avoid repetition with it, language compatibility/integration simplicity
<elvishjerricco>
__monty__: Probably don't *need* it, but the stuff we do with the module system would be very difficult in a total language.
<__monty__>
Maybe the exact way it's done. But that's like saying it'd be hard to do in a statically typed nix. I still think it might be worth any troubles.
<infinisil>
__monty__: Have you tried implementing a simple module system like the one we have in NixOS in Haskell? I tried once and quickly stopped because I had to idea how it could work
<infinisil>
I didn't know haskell as well as I do now though, so not sure
<elvishjerricco>
__monty__: I dunno. I'm having a hard time thinking of a way to make something as nicely configurable as NixOS without fix. Replicating the ability to override any setting and the ability to reference the *final* values of arbitrary options is pretty fix-y
<__monty__>
I'm not saying the exact system there is now would be easy to implement in another language.
<elvishjerricco>
infinisil: I think it wouldn't be too bad in haskell
<infinisil>
elvishjerricco: How do you solve the problem that any module can define new arbitrary options though?
<infinisil>
I could even define module A that defines the option a, and module B that defines the option b, with a default value of each other, a = mkDefault b; b = mkDefault a
<elvishjerricco>
__monty__: Of course, but I think getting something with the same advantages as the module system, regardless of how closely it resembles the module system, would be hard in a total language.
<elvishjerricco>
infinisil: You could just be lazy and have a lazy map of option names to values :P
<elvishjerricco>
otherwise there's a few extensible records approaches that could do it