<__monty__>
I seem to remember wormhole codes are supposed to be composed from words with redundant information from an early presentation about them. So you could quite easily dictate the code over a phone and the receiver could basically make as many typos as they wanted and it'd still work. This doesn't seem to be the case in any implementations though. Does this ring a bell for anyone? Maybe I'm confusing
<__monty__>
wormhole codes with something else?
__monty__ has quit [Quit: leaving]
iqubic has quit [Ping timeout: 268 seconds]
iqubic has joined #nixos-chat
<colemickens>
bip39 uses words that are uniquely identifiable from any three characters I think.
<infinisil>
colemickens: (it's the 4 first chars)
<colemickens>
oops, thanks :)
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 250 seconds]
lassulus_ is now known as lassulus
<ivan>
TIL don't run automatic nix gc on the machine with morph because the morph builds aren't registered as gc roots
<iqubic>
OOF. Sorry to hear about that.
<ivan>
do you work on it? maybe the last few builds should be registered or something
<ivan>
actually I guess that gets tricky when building less than all of the machines
<srk>
colemickens: I've lost faith in RHs tech few years ago :D
drakonis has quit [Quit: WeeChat 2.3]
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 268 seconds]
ottidmes has quit [Ping timeout: 264 seconds]
<colemickens>
I read through the FAQ a bit more closely and sort of lost interest.
<srk>
in the end it's all about cddl/gpl compatibility which prevents them distributing zfs
jackdk has quit [Ping timeout: 250 seconds]
endformationage has quit [Quit: WeeChat 2.3]
<srhb>
elvishjerricco: Are you around? I've been trying to switch to grub on my luks+zfs setup without luck, and I think you did that at some point.
<jasongrossman>
I may have misread what the devs thought previously. Anyway, this is great.
<gchristensen>
it was never in any real peril
<simpson>
ZoL maintainers like to whine and to use their userbase as leverage. Sounds like the drama's over.
<drakonis>
sounds about right
<drakonis>
why not just prepare to relicense it, the openssl and llvm folks are doing it
<gchristensen>
not sure it is really feasible
<drakonis>
rather, they have succeeded
<simpson>
drakonis: Heck, given their timeline, they could have rewritten ZFS's core in a Linux-friendly style and gotten it upstreamed.
<drakonis>
certainly but
<drakonis>
gotta be petulant too
<gchristensen>
I'm not sure this is a healthy conversation to have in public
<drakonis>
probably not.
<drakonis>
its also logged
<simpson>
Oh noes, people will know of my distaste for projects which leech off the Linux kernel.
<drakonis>
its hot eh
tertl3 has joined #nixos-chat
<infinisil>
42'000 closed PR's right
<infinisil>
now
<gchristensen>
incredible
<drakonis>
fantastic.
<drakonis>
still stuck at 1050 pull requests though
<drakonis>
these keep flowing in
jackdk has joined #nixos-chat
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
<infinisil>
I feel like I'm reviewing lots of PR's, suggesting changes, but lots of people never really make the changes and the PR just stalls
jasongrossman has joined #nixos-chat
jasongrossman has quit [Remote host closed the connection]
jasongrossman has joined #nixos-chat
jasongrossman has quit [Read error: Connection reset by peer]
<samueldr>
it's never going to zero, and will always increase; there is a backlog of PRs with merge conflicts that authors would need to fix (ideallly) or be fixed by the community, and considered even before "yes we want" or "no we don't"
<samueldr>
add to that, the WIP PRs
<joepie91>
infinisil: perspective from the perpetually-busy-PR-maker side of the fence: I have to carve out time to work on a PR, and after I've made it then I have like 30 minutes where I'm winding down and preparing for something else... if feedback of some sort arrives within that 30 minutes (even if it's just "looking at it, will have more feedback in an hour") then I can keep working on the PR, but if it takes longer than that then I'll have context-
<joepie91>
switched to something else and will need to schedule a new slot to work on any feedback
<joepie91>
I've heard a few other people describe this same thing (not in the context of Nix specifically)
<joepie91>
so maybe the ideal approach is to prioritize reviewing the PRs that were made within the last 30-60 minutes of when you're looking at the open PR, instead of trying to address older ones first
<samueldr>
my train of thought is to think of that number as something you use to gauge whether it has gone up or down lately; like inbox zero, PR zero on such a huge project is probably unattainable, and is not a sign of health
<joepie91>
at the open PRs *
<jackdk>
infinisil: I'm on the PR-maker side. Both sides can feel like writing letters into the void, but I certainly appreciate your work and the work of the other maintainers
<joepie91>
that way you might catch more people in their still-paying-attention time
<samueldr>
though I think GitHub lacks tools to *manage* PRs more efficiently, their search is not good enough imho
<samueldr>
you can't easily bookmark or earmark PRs
<infinisil>
joepie91: That's certainly an argument. But one can't expect a (non-trivial) PR to be a one-time job. PR's get reviews, need to be updated, etc.
<joepie91>
infinisil: oh, sure. the idea is more to 'keep the conversation flowing'
<joepie91>
most of the back-and-forth on a PR is not going to involve complex thinking processes
<jackdk>
and that's before all the timezone stuff. You could also ping old PRs and say "are you still interested in working on this?" so you know where to spend braincycles
<joepie91>
so if you can cut down on those back-and-forth iterations by replying quickly, that can cut down the total time for handling a PR a lot, I think, and require a lot less context switches
<infinisil>
Hmm yeah, so I think maybe a balance between old PR's and PR's in brain RAM would be optimal
<joepie91>
even if you then still have some cases left where somebody needs a month to figure out a tricky issue :)
<joepie91>
(I also think that part of the problem here is on the part of github, because their interface isn't really built with this kind of semi-realtime interaction in mind)
<__monty__>
joepie91: OTOH, I've found that being very responsive begets single line replies and tons of silly questions you just want to answer RTFM to.
<joepie91>
dunno, especially in the context of Nix and its community and state of documentation, I'm inclined to treat 'silly questions' as involuntarily filed documentation bugs :)
<joepie91>
I've found Nix people to make a lot of effort on average to figure out stuff themselves
<gchristensen>
a selection bias
jasongrossman has joined #nixos-chat
<joepie91>
oh, for sure
<joepie91>
but one that can work in our favour for now
<gchristensen>
a nice selection bias ;)
<jackdk>
a bias, to be sure, but a useful one
<drakonis>
samueldr: have you looked into sr.ht?
<drakonis>
other than it raising the contribution bar a fair bit, it seems to be better than github
<joepie91>
sr.ht is horrible in terms of UX
<drakonis>
obviously, yes.
<drakonis>
not unlike git though :V
<mdash>
bad ux is often a good business practice
<simpson>
sr.ht also only has one owner and they're an asshat. Which might be acceptable for some folks.
<drakonis>
its FOSS
<LnL>
I've had people claim it's not when I use it as a comparison to the nix ux
<drakonis>
AGPL3.0
<gchristensen>
LnL: :d
<drakonis>
i'm obviously not a big fan but its fully free to use
<drakonis>
i wouldn't bet on github staying any decent in the future
<joepie91>
I mean, there's no shortage of crappy FOSS project management interfaces :)
<joepie91>
the problem is the lack of *good* ones
<LnL>
gchristensen: perfect example of being bias about something familiar vs new :)
<drakonis>
i dig sr.ht because its not too different from running a project from before github
<mdash>
joepie91: there's a lack of good everything
<mdash>
joepie91: i mean, as much as i like nix, it's still based on unix
<joepie91>
we don't disagree :)
<__monty__>
Is it really though? Maybe I'm thinking Guix.
<drakonis>
guix runs on hurd
<drakonis>
i'd appreciate nix more if it was easier to run chroots for software outside the scope of nix
<drakonis>
an age old argument
<gchristensen>
eh?
<drakonis>
its the "i wanna download and run this stupid binary off the net but it needs patching"
<drakonis>
argument
<gchristensen>
gotcha
<gchristensen>
like steam-run but more general / magic?
<drakonis>
yes
<joepie91>
speaking of which
<joepie91>
I had an appimage fail to run recently
<joepie91>
with appimage-run
<joepie91>
need to file a bug...
<tilpner>
hi
<joepie91>
cura I think
<drakonis>
hey
<tilpner>
what error?
<joepie91>
tilpner: was that aimed at me? :P
<tilpner>
Yeah, you can file your bug to me
<joepie91>
heh, okay :) one moment while I repro
<drakonis>
gchristensen: there's also dealing with having to package several one offs just for another oneoff package but podman is available now
<tilpner>
So use appimage-run.override { extraPkgs = p: with p; [ krb5 ]; } instead
<tilpner>
That's it, you're on your own, good night :)
<joepie91>
weird, I would've expected that to have been bundled
<joepie91>
anyway, thanks
<joepie91>
night :)
<joepie91>
tilpner: also, feature suggestion: add -p flag or something to appimage-run to inject specific deps so that you can do eg. `appimage-run -p krb5 curablahblah.appimage`