Doesn't really fall under SCAM, does it? There's nothing meetup-related
guusdk
nyco: good idea
guusdk
But it should be tweeted nonetheless
MattJ
+1
nyco
oh commteam
MattJ
Yeah, sorry, I realised it was probably just a typo after I wrote my message :)
nyco
we also should tweet every call for membership
MattJ
Ok, I think we're done then
MattJ
7) Next meeting
MattJ
+1 week
guusdk
+1
nyco
+1
guusdk
Ok
MattJ
8) The End
MattJ
Thanks all
nyco
thx all!
guusdk
Thanks
Neustradamushas left
Neustradamushas joined
MattJ
Aha
MattJ
I think I found what's up with xmpp.org
MattJ
Well, the XMPP service anyway
MattJ
Currently holds 1020 open fds, limit is 1024
Zash
It uses select???
Ge0rG
Le Sigh.
MattJ
ulimit
Zash
Oh
Ge0rG
https://issues.prosody.im/536
MattJ
Ah, fun
MattJ
The majority of open fds are UDP sockets "connected" to the DNS server
MattJ
which was down earlier in the week, so I guess that constitutes a bug
Zash
https://issues.prosody.im/1170 ?
MattJ
Except this server is many versions out of date, so probably just needs an upgrade
Ge0rG
I remember having a server silently running out of FDs. It sucks.
MattJ
Oh no, it's not out of date, apparently I upgraded it at some point
tuxhas joined
tuxhas joined
MattJ
Zash, so I guess you can take NeedInfo off that issue :)
Zash
Is this even 0.10.x?
MattJ
0.10.2
Zash
MattJ: That change isn't in 0.10.2
MattJ
Ah
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
MattJ
Ok, service should be restored for now
nycohas left
danielhas left
danielhas joined
Ge0rG
did you throw in some more sockets?
jonas’
prosody should just re-exec itself when it runs out of sockets /s
Steve Killehas left
alacerhas left
Ge0rG
jonas’: message to all admins and reexec
Zash
Why
Zash
And how
Ge0rG
Zash: it will close all sockets.
ThibGhas joined
danielhas left
flow
Ge0rG why not simply monitor the open fd externally and send an (XMPP) message?
flow
*open fd count
jonas’
Ge0rG, let me tell you about my botnet opening 65535 TCP connections to your prosody instance :>
jonas’
flow, "simply" and "monitor" and "prosody" in a single statement is daring
Zash
"fd count" is painful as well
flow
jonas’, I think it could be done prosody agnostic, i.e. not specific to a particular process binary, you just monitor if your process is running against the open fd limit
Steve Killehas joined
jonas’
flow, picking the right process to monitor isn’t easy either
Ge0rG
flow: feel free to PR against https://issues.prosody.im/536
MattJ
Ge0rG, PR for an external script?
MattJ
I'll repeat what's already said in the issue: there is no API for asking the OS how many fds you have open
MattJ
So file an issue for Linux
Zash
I haven't even seen anyhing in the epoll API that tells you how many FDs you are watching
Zash
Easy enough with select() since you have to manually add them for every call
jonas’
open /proc/self/fd, count number of entries?
Zash
But then you're limited to sizeof(fd_set) * (bits per byte)
Zash
jonas’: That's mentioned in a comment in the issue already
jonas’
sorry :)
Ge0rG
MattJ: the external script could be part of the OS-level packaging and tooling
matlaghas left
matlaghas joined
Zash
File an issue for systemd
MattJ
Talking about epoll/etc. is besides the point... fds != connections
Ge0rG
isn't this all about fds only?
MattJ
You suggested select/epoll in comment 6
MattJ
and I pointed out what I just pointed out (fds != connections) in comment 7
Zash
All this has happened before, and all of it will happen again, and again, and again.
Zash
What jonas’ said is comment 8
MattJ
The only way to correctly implement this is an O(N) loop, run $frequently
Zash
Can you get the size of a directory in O(less than n) in Linux?
Zash
Or does that just move the O(n) elsewhere?
efrithas joined
Ge0rG
MattJ: you are the one bringing up connections all the time.
Zash
Or are /proc directory entries too magical for that
Ge0rG
Zash: opening /proc/self/fd requires... a free fd
Zash
Dun dun DUN
matlaghas left
matlaghas joined
Ge0rG
I wouldn't be surpsised if sending a message to admins would also require a free fd.
Ge0rG
or multiple ones.
Zash
Might, yes
Ge0rG
Can't you just detect EMFILE from any fd you open and trigger an error condition on that?
Ge0rG
BTW, this MUC is exceptionally laggy today.
Zash
Storage might need a FD to write to eg offline storage or archive
Zash
Don't we already?
blablahas left
Zash
Wow, that is laggy
Ge0rG
MattJ: did prosody run out of descriptors again?
Zash
But not now?
Zash
.
Zash
Apparently it is
Zash
17:00 now
Zash
25s lag
Zash
Catching up with something?
Ge0rG
xsf@muc.xmpp.org did not respond to ping after 10s: timeout
Ge0rGshakes fist at poezio
jonas’
ping
jonas’
wfm
jonas’
very fast from here
Zash
.
Ge0rG
sometimes it's fast, and sometimes it lags. swap disk thrashing?
jonas’: re my question earlier, can you expand on your decision to move 0392 to HSLuv? You claim it has widespread library support, but the ones I've found are *really* terrible, and I think there was some value in using a standard color space. HSLuv may look nice, but it has no real applications in insdustry and isn't likely to be widely supported, so I'm skeptical of that claim
SamWhited
I'm not specifically for YCbCr to be clear, I don't care what colorspace is used it just seems like there's value in using a standardized one
SamWhited
not just some random persons personal project that's not used anywhere
guusdkhas joined
jonas’
right
jonas’
so, what we did on top of YCbCr is essentially what HSLuv does on top of CIE XYZ, but worse
jonas’
so it’s a home-brew solution either way
jonas’
except that HSLuv gives better results
SamWhited
I didn't remember you making changes to YCbCr, what did you do on top of it?
jonas’
the algorithm to determine CbCr based on the angle
jonas’
or rather, based on the 16 bit input extracted from the hash
SamWhited
That's just picking a color out of the space, that seems fine; you'll have to do that no matter what space you use
jonas’
that’s what HSLuv does on top of XYZ anyways
jonas’
but the results are much more uniform than what we had with YCbCr
SamWhited
Hmm, I didn't understand that; it's an entirely new colorspace as far as I could tell, maybe I need to go reread their definition of it
jonas’
http://www.hsluv.org/math/
jonas’
oh, it works on top of CIE LUV LCh, not XYZ
jonas’
not sure where I got the XYZ from
jonas’
it is really pretty much exactly what we did with YCbCr: use Hue as angle, cast a ray to the border, take value
SamWhited
Yah, that's not the same thing at all; it's a brand new color space, they've just defined it as a transformation of CIE LUV
SamWhited
You couldn't just pick a color from an eisting CIE LUV implementation, as far as I can tell from this
jonas’
so, old XEP-0392 was just an entirely new color space which can be defined as a transformation of YCbCr; that’s wordplay
SamWhited
I don't think that's true, these are two different things
SamWhited
If I had the set of all possible colors in YCbCr I could do you algorithm and get colors in that set (I think?)
jonas’
no
SamWhited
If I have the set of all colors in CIE LUV I can't do 0392 with that, I have to implement HSLuv first
jonas’
no wait, I don’t understand what you’re saying
alacerhas joined
jjrhhas left
SamWhited
I'm saying that if I have a CIELuv implementation I can't implement 0392 with that; it will be different colors than if I start from an HSLuv implementation.
SamWhited
And HSLuv isn't actually a standard that anyone recognizes, and contrary to your claim doesn't have very good library support as far as I can tell
jonas’
SamWhited, I didn’t review all the implementations in http://www.hsluv.org/implementations/ but at least the Python and Java ones seem to be fine
jonas’
the C one, too
SamWhited
I reviewed a few; they were mostly terrible, unidiomatic, and unmaintained.
SamWhited
They're examples, but not actually something I'd use in prod
SamWhited
And either way it seems like there's valule in using a widely recognized standard and not something where the only support will come from a single party
danielhas joined
jonas’
maybe
jonas’
however, the results with YCbCr are not as nice as HSLuv
SamWhited
Maybe if you want those specific colors it would make sense to define 0392 in terms of CIE Luv which I think is widely standardsized and just include the math for going to HSLuv (and you could mention that if you have an HSLuv implementation you can just start from their)?
jonas’
that would make 0392 unnecessarily long
SamWhited
They look about he same to me, if anything I've gotten more gross mustard yellow since Conversations updated, but that's probably just bad luck
jonas’
the difference is in the uniformity of brightness
jonas’
lemme grab you a screenshot
SamWhited
Yah, the brightness uniformity is nice, but it doesn't outweigh the downside in my opinion; there has to be a standardized colorspace or subset of one that has uniform brightness?
jonas’
not really, unless you do exactly what HSLuv does
jonas’
maybe on top of something else
lovetoxhas joined
jonas’
but you end up using one of the photometric ones (XYZ, LUV, you name it), and do a solve() to determine the right color for a given hue and saturation
SamWhited
I dunno, personally if the only benefit is more uniform brightness that's nice, but doesn't make it worth using a colorspace that has a total of one implementation in a few languages and isn't actually used anywhere and that no one has any experience with
404.cityhas left
SamWhited
It doesn't seem like it would be that much more to describe how to construct this colorspace though, but maybe I'm being over optimistic, I need to look over the math and actually try to understand it
SamWhited
Since I'd have to do that to implement it anyways
jonas’
the golang implementation doesn’t look too bad to me, but I don’t know lots of go either way
SamWhited
It's bad
SamWhited
That one in particular is more or less unusably bad; there are standard interfaces for doing colors in go which it doesn't implement.
SamWhited
Also the code just isn't idiomatic
SamWhited
And is impossible to follow or reason about because of the way they've defined it as transformations through multiple other colorspaces
jonas’
color spaces are all a mess, unless you go to the photometric ones
jonas’
and converting the good photometric ones (CIE LUV in this case) to one you can use to display something on a computer is where you get the mess you save by doing stuff in photometrics
SamWhited
I get that that's a pain, but it still seems worth using an actual standard
SamWhited
Even if it doesn't look as great; YCbCr seemed fine to me personally
blablahas left
SamWhited
Actually, specifically looking at Go right now (I'd like to implement this in Go and Rust) I can't find a CIELUV implementation either, which suprises me
jonas’
I’m not surprised.
SamWhited
I guess that one's not all that widely used, even if it has been standardized for a while
SamWhited
So maybe starting from that wouldn't help, I haven't looked at other languages yet though