<elvishjerricco>
Should zfsUnstable be updated to 2.0-rc1 now that that's out?
<infinisil>
:O
<infinisil>
I'd say yes!
<infinisil>
Makes me think, NixOS options like `enableUnstable` are kind of bad, because most users just want to temporarily enable it
<infinisil>
Maybe this should rather be something like `unstableVersion = lib.mkOption { type = types.enum [ "0.8-rc1" "2.0-rc1" ]; }`
<infinisil>
Where users will get an error if they select an unstable version not available anymore (because it's stable)
janneke has quit [Quit: janneke quits Mes'sing]
janneke has joined #nixos-dev
<elvishjerricco>
infinisil: Eh, I see `enableUnstable` more like the nixos-unstable channel; it just keeps advancing faster than stable, even if a lot of it is effectively the same as stable
<elvishjerricco>
s/faster/more aggressively/
<infinisil>
elvishjerricco: Hm yeah. However I think we should distinguish between unstable as in "can just rollback if it breaks" and "oh no, I lost all my data"
<infinisil>
For the former I think an `enableUnstable` option is fine. But for the latter, a `unstableVersion` one would be better
ris has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
rajivr has joined #nixos-dev
<samueldr>
in that mind set, why artificially limit how the package is set through a bool, and not set .package? (or for those that are against .package, let users manage that through an overlay)
<elvishjerricco>
How do I get `machine.succeed` to output the command's stderr and stdout to the log?
<elvishjerricco>
Regardless of if it succeeds or fails?
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
janneke has quit [Remote host closed the connection]
janneke has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
cole-h has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<JJJollyjim>
elvishjerricco: iirc something along the lines of machine.succeed("thecommand | systemd-cat")
<JJJollyjim>
I really want to make the test driver stream command output to the log automatically, the status quo can make debugging pretty annoying
<elvishjerricco>
*sigh*, updating zfsUnstable to 2.0-rc1 is going to require even more substituting /bin, /sbin, /usr/local/bin, etc...
<elvishjerricco>
I'm too tired for that right now. Why are people so against PATH?
sgrunert has joined #nixos-dev
FRidh has joined #nixos-dev
teto has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
alp has joined #nixos-dev
FRidh has quit [Ping timeout: 258 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
lightbulbjim has joined #nixos-dev
lightbulbjim has quit [Quit: Connection closed for inactivity]
lightbulbjim has joined #nixos-dev
<Mic92>
worldofpeace: spacekookie sphalerite are you in the meeting today? If we don't have at least three people we, we cannot have the meeting today.
<Mic92>
niksnut said he is on vacation
<spacekookie>
I'm still on sick leave until end of next week
<niksnut>
Mic92: no I'm not on vacation
<Mic92>
niksnut: ok. than we need just one more
<sphalerite>
Mic92: yep I can make it
v0|d has quit [Remote host closed the connection]
<infinisil>
samueldr: Oh yeah a package option sounds even better
<infinisil>
Though then there's the same problem with pkgs.zfsUnstable
<infinisil>
So maybe it should be pkgs.zfs_2_0_rc1 instead, and zfsUnstable be removed
<Mic92>
infinisil: we need zfsUnstable every once in a while
<Mic92>
Sometimes we point to master
<infinisil>
Mic92: Did you see my argument regarding enableUnstable above?
<Mic92>
infinisil: the semantic of enableUnstable is that it only points to unstable if the latest kernel is not supported otherwise.
<Mic92>
so if 2.0-rc1 unlocks newer kernel we will point to that.
<Mic92>
if you are running linux_latest you likely need zfs unstable sooner or later.
<infinisil>
Yeah but the problem about it being able to wipe all your data is still there. That's the thing I'm worried about
<Mic92>
than you should not use it
<Mic92>
and run stable.
<infinisil>
Well yeah, see my point above
<Mic92>
I don't get your point
<infinisil>
02:42:35 infinisil | Makes me think, NixOS options like `enableUnstable` are kind of bad, because most users just want to temporarily enable it
<infinisil>
02:43:50 infinisil | Maybe this should rather be something like `unstableVersion = lib.mkOption { type = types.enum [ "0.8-rc1" "2.0-rc1" ]; }`
<infinisil>
02:44:26 infinisil | Where users will get an error if they select an unstable version not available anymore (because it's stable)
<Mic92>
if it becomes stable than zfsUnstable will point to stable.
<infinisil>
If you enable `enableUnstable`, you'll get the unstable version at that point. But if you then update nixpkgs, it might break your setup because unstable was updated to a "too unstable" version you haven't evaluated yet
<infinisil>
What if there's a seriuos bug in zfs master that can wipe all your data for example. And nixpkgs happens to update zfsUnstable to it. For everybody having `enableUnstable` this could be pretty bad
<infinisil>
Which is why I'm arguing that the user should *select* the unstable version they want, e.g. 2.0-rc1, such that if unstable is updated, they need to cosciously change an option to match the new unstable
<infinisil>
*If* they still want to use unstable that is
<niksnut>
sphalerite: joining?
<infinisil>
The fundamental reasoning is that it's unsafe to update from "unstable -> another unstable". In comparison it's presumably always safe to update "stable -> another stable"
<Mic92>
how is this different from running linux_latest?
<Mic92>
It could also have a bad bug that make you loose all your data.
<Mic92>
It's not like there are no regression tests.
<infinisil>
Mic92: linux_latest is still stable though
<infinisil>
And linux doesn't manage your data, the chance of making it loose all your data is negligible
<infinisil>
In comparison, zfs unstable could be disastrous
<infinisil>
And that without warning
orivej has joined #nixos-dev
lightbulbjim has quit [Quit: Connection closed for inactivity]
<Valodim>
no idea how much of an issue this is in practice
<sphalerite>
right, but you need to upgrade a pool manually for it to become incompatible.
<Valodim>
true
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
bennofs__ has joined #nixos-dev
bennofs_ has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 272 seconds]
ris has joined #nixos-dev
sgrunert has joined #nixos-dev
<eyJhb>
Does it make sense, to use Nix to build a configuration that I can convert to Yaml? (there would be more to it of course, it would be used in a build process, where tho module inputs would be in the output as something.yml)
cole-h has joined #nixos-dev
<samueldr>
it might
<samueldr>
and you might be able to just output it as json, as yaml is (supposed to be) a superset of json
<eyJhb>
I should do a POC, but I think it needs to be yaml, as it should be SOMEWHAT easy to edit
<eyJhb>
*sigh* slowly getting better at Nix, but there is sooo much to learn.
<eyJhb>
But it feels hacky to use Nix, because I will not get many to use it, and might scare some off. But on the other hand, we might get more people into Nix!
rajivr has quit [Quit: Connection closed for inactivity]
* cransom
votes no on YamlOS.
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
alp has joined #nixos-dev
teto has joined #nixos-dev
teto has quit [Client Quit]
alp has quit [Ping timeout: 240 seconds]
sgrunert has quit [Remote host closed the connection]
<infinisil>
eyJhb: You just want to do a module evaluation with these options?
<infinisil>
And nothing else?
<eyJhb>
Want to create a instance that has these options, e.g. I want to have optSet1, optSet2, optSet3, then have these options and convert them to JSON/yaml and put them into a file
<eyJhb>
Does that makes sense infinisil ?
<eyJhb>
Basically the goal is still, in the form of cyber sec, where I might clone a repo with challenges, and then create config files for each challenge in the repo. So I can just nix-build to create all the challenge configs I need
<samueldr>
you could even make the `writeText` part a function taking in a configuration attrset
<eyJhb>
Ahh, I see now, thanks!
<samueldr>
btw, both `config` and `options` technically respect the "Example 44.1. Structure of NixOS Modules"
cole-h has quit [Quit: Goodbye]
<samueldr>
uh, not both config and options, but the `config` attrset, and the attrset that has the `options` value
<samueldr>
see, there is the "abbreviated" format, where if you don't have options declarations you can define config values at the root
<samueldr>
(not sure if I'm helping or causing confusion)
<eyJhb>
Mostly confusion, but that is a general theme for me with NixOS
<samueldr>
it all ends up making sense at some point
<eyJhb>
Hoping so! Just need to put enough time into it
<eyJhb>
Does Nix function well with building vbox images?
<samueldr>
I think so, as one is built as part of the outputs of NixOS
<eyJhb>
But does it only work with NixOS builts, or can I build e.g. Debian?
<eyJhb>
Currently one of the biggest reasons I want to use Nix for building these challenges is, that when I want to pull stuff in from other repos, sources etc. they fill a TON! So just having .nix files, where I can build and maybe even specify what I want would be ideal. E.g. https://github.com/google/google-ctf is 200+ MB in size, which is one of the first ones I would pull in. ALso having defaults
<eyJhb>
in options, without having to hack around and figuring out, where to place the defaults in my Go code instead
<samueldr>
good question about debian
<samueldr>
we do have the ability to build a *qemu* vm for debian
<samueldr>
maybe it can be combined?
<adisbladis>
eyJhb: In personal projects I use Nix as an excuse not to have config file parsing ^_^
<adisbladis>
Why have a config file when I can use Nix to generate a command line
<adisbladis>
eyJhb: I don't know what your packaging requirements on Debian are, but maybe fpm is for you?
<adisbladis>
> fpm.meta.description
<{^_^}>
"Tool to build packages for multiple platforms with ease"
<eyJhb>
adisbladis: generally I just need some docker and vbox I assume, qemu might work as well
<eyJhb>
I just want to get this project off the groud sooooon
<eyJhb>
ground* will work a little more on the basics tomorrow, and then I can hopefully make my monorepo thingy
<eyJhb>
But all the guys involved in the project, are not Nix fans. So hard to push anything with it :p
<eyJhb>
Unless I can make the most sweet sweet lib ever
<eyJhb>
Currently my idea, is to have all the small building blocks for challenges, such as web content, basic versions of libc, etc. available which can then be pulled in
<eyJhb>
samueldr++ infinisil++
<{^_^}>
infinisil's karma got increased to 341
<{^_^}>
samueldr's karma got increased to -2147483648