<Mic92>
What I like about it, is its comparable low code complexity compared to zfs/btrfs.
<Mic92>
For example do this: lsmod | grep zlua
<gchristensen>
lol yeah that is a Thing.
<Mic92>
Why does my filesystem needs a lua interpreter?
<Mic92>
It's not even used by anything.
<gchristensen>
so you can write and run complex ZFS operations atomically :)
<gchristensen>
maybe I should have made that one an (:
<Mic92>
or deadlock my system because of some endless loop.
<Mic92>
*inifinite
<gchristensen>
endless loops won't deadlock your program, they have a somewhat conservative limit to their execution
<Mic92>
At least something. My main uses cases of zfs is still its stability and snapshots. My machines crash sometimes because of kernel stuff that I do...
<gchristensen>
no, if you want to deadlock your system with it you'll have to call gsub a bunch of times
<gchristensen>
I think it'd have been smarter to let the zfs channel programs run as root, and use an ioctl or something to take a lock during the execution and keep lua out of the kernel
<Mic92>
Or if you really going for the lua way at least compile it to ebpf.
<adisbladis>
Mic92: I just remember koverstreet submitting some patches to mainline and the discussion turning into a cluster ****
<adisbladis>
Since then, nothing popped up on my radar re bcachefs
<Mic92>
I won't go upstream before the on-disk datastructures are final.
<adisbladis>
Mic92: This was about introducing some new type of lock iirc
<Mic92>
adisbladis: are you on the kernel ml?
<adisbladis>
Mic92: No
<puck>
Mic92: ZCP exists on platforms other than linux, and was actually introduced in illumos
<Mic92>
puck: I know. Still sucks.
<puck>
Mic92: so using eBPF is out of the question, never mind that running lua in the kernel isn't that crazy tbh
<puck>
i'd rather have lua over eBPF for this, to be completely clear
<Mic92>
I mean I don't notice it actually because I am not using.
<puck>
(also the lua interpreter has been modified to stop after N instructions, and M memory)
<gchristensen>
I wish it was atomic in ways I care about, like either fully succeeding or having no effect
<gchristensen>
instead of the borrowing the word atomic to mean exclusive write lock
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
<JJJollyjim>
oh jeez i was reading scrollback and saw "kernel ml" and my brain filled in "kernel machine learning"
<gchristensen>
you mean the way they decide to backport patches?
<JJJollyjim>
i'll take lua over that
<JJJollyjim>
lol
<JJJollyjim>
Oh no this is real
<gchristensen>
well that feels like a highlight of my morning
<eyJhb>
JJJollyjim: Is Kernel Machine Learning real?
<tazjin>
gchristensen: fortunately there's a larger edit distance between tazjin and gchristensen :p
ryantm has quit [Quit: authenticating]
<gchristensen>
that was talyz's date
ryantm has joined #nixos-dev
<talyz>
:D
tazjin is now known as nijzat
<JJJollyjim>
7y 11w
<nijzat>
talyz: I challenge you to a duel
<talyz>
It'll probably be hard to switch my nick after having used it for about 15 years :p
<JJJollyjim>
i am little baby
* nijzat
pets JJJollyjim
talyz is now known as zylat
bachp has left #nixos-dev ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<eyJhb>
nijzat: perfect
<eyJhb>
zylat:PERFECT :D
<eyJhb>
Just, STAY now :p
zylat is now known as talyz
abathur has quit [Quit: abathur]
andi- has joined #nixos-dev
<talyz>
nijzat: the nix duel of the nicks
<gchristensen>
oh no
<infinisil>
Idea: What if we pranked everybody on April 1 by changing all our nicks to look almost identical :P
<marek>
to gchristensen? :)
<makefu>
gchristensens
<lewo>
gchistsuite
nijzat is now known as tazjin
<adisbladis>
infinisil: I'm in a channel where we have a yearly tradition to switch nicknames to a 4 letter one. The two first letters from your forename and the two first letters from your surname
<infinisil>
Hehe neat
tazjin is now known as tazjylin
<adisbladis>
tazjylin: Perfect
<adisbladis>
infinisil: I'm pretty happy that channel is not on freenode tbh
<adisbladis>
That would be annoying
<infinisil>
Yeah, with nick changes being per-network
tazjylin is now known as tazlyjin
tazlyjin is now known as tazjin
<ajs124>
hah! I knew there was a reason to keep around this old e-mail address I haven't really used in 8 years!
<ajs124>
I just checked my freenode nick info and I used it there and never changed it.
ckauhaus has quit [Quit: WeeChat 2.7.1]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
<doronbehar>
Hey all, there's a sort of "hot argument" at #89453 I think someone should get involve inorder to cool things down. I tend to agree with the PR author but I'm not strongly opinionated.
<c00w>
doronbehar: also thanks for noticing + helping, I'd basically given up a month ago when it feel apart.
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
<edef>
broadly i don't *really* think the existing vgo2nix impl is the way to go
<Mic92>
c00w: Sorry I lost your progress out of sight
<Mic92>
c00w: looks like you fixed everything?
<edef>
but building new tooling off golang.org/x/tools/go/packages + golang.org/x/mod/module is not hugely difficult
<edef>
we have such a tool internally at Mutable, but it relies on https://code.tvl.fyi/about/nix/buildGo, and i haven't had the time to make it more robust and publish it
<Mic92>
edef: does it makes those definitions automatically?
<Mic92>
Otherwise it will be too much work to maintain it for our go packages.
<edef>
Mic92: this is what the definitions my tool outputs look like https://clbin.com/YhPH4
<c00w>
Mic92: I'm not really a good person to answer that. My current status is "believe reviewer will change acceptance criteria forever so I've given up". AFAICT there are no bugs in the current code any one has pointed out, so it should be mergable.
<Mic92>
c00w: looks good to me. Last time I looked there were still some unresolved issues.
<Mic92>
It's a big project so its sometimes hard to keep track of every change people do.
<Mic92>
In fact I also forgot that your PR existed
<c00w>
Mic92 - nw, I think you've always been a good reviewer. I've also basically ignored that PR for a month so I can't judge anyone else for slowness.
<infinisil>
gchristensen: What if these mega-hashes are allowed, but only for directories of unpacked sources
<infinisil>
Like a set of fetched and unpacked zips, 20 of them in a folder
<infinisil>
This wouldn't be brittle then, and it means you don't need to provide all those hashes, but only a single one
<Mic92>
gchristensen: In my opinion having a single hash is better than big generated expression.
<Mic92>
Because how do I know nobody manipulated those without re-running the generator again.
<Mic92>
I mean for got its still a manageable size, but nodejs is a night-mare
<edef>
for Go there's the sumserver
<infinisil>
Mic92: I don't get that reasoning
<edef>
so you can verify that the hashes match
<gchristensen>
what are you optimising for where that is better? when I consider it better, I'm optimising for getting the same result later, and I've found those megahashes to be not good at that
<qyliss>
example: cargo-vendor regularly makes slight changes to the big vendor directory it produces
<edef>
(unfortunately, they use a different hash format that we don't interoperate with)
<Mic92>
infinisil gchristensen : If somebody updates pkgs/development/node-packages/node-packages.nix they could all kinds of shenanagins in it.
<Mic92>
And it's a nightmare to backport
<qyliss>
Yeah node-packages.nix isn't in a good place
<gchristensen>
I understand that for sure
<infinisil>
Yeah node-packages.nix is not very nice, but that's just because it's a single expression used by many packages
orivej has quit [Ping timeout: 258 seconds]
<infinisil>
Wouldn't be bad if every package had its own one
<Mic92>
well we cannot have many packages it would just explode nixpkgs in size and evaluation time
<infinisil>
(wouldn't be bad in that way at least, would be bad in other ways)
<gchristensen>
:D
<qyliss>
We have had problems again and again from programs that download something, do some computation from it, and then produce a supposedly canonical output
orivej has joined #nixos-dev
<Mic92>
Well for go it's now literally the source code of each dependency without extra.
<ryantm>
It would be acceptable if you didn't have to check that every URL isn't some random URL thrown into a 1000 line change.
<qyliss>
Mic92: can the layout change?
<qyliss>
The problem with node-packages.nix isn't even so much that it's one file, it's that npm will update random unrelated packages when you ask it to add a new one.
<infinisil>
ryantm: Would be interesting if nixpkgs only allowed auto-generated expressions from CI. So e.g. we'd have a job that runs every week that updates node-packages.nix
<infinisil>
People can't update it themselves
<Mic92>
qyliss: Unlikely it has been standardized by go itself and other third-parties are relying on it