MattJDoesn't really fall under SCAM, does it? There's nothing meetup-related
guusdknyco: good idea
guusdkBut it should be tweeted nonetheless
MattJ+1
nycooh commteam
MattJYeah, sorry, I realised it was probably just a typo after I wrote my message :)
nycowe also should tweet every call for membership
MattJOk, I think we're done then
MattJ7) Next meeting
MattJ+1 week
guusdk+1
nyco+1
guusdkOk
MattJ8) The End
MattJThanks all
nycothx all!
guusdkThanks
Neustradamushas left
Neustradamushas joined
MattJAha
MattJI think I found what's up with xmpp.org
MattJWell, the XMPP service anyway
MattJCurrently holds 1020 open fds, limit is 1024
ZashIt uses select???
Ge0rGLe Sigh.
MattJulimit
ZashOh
Ge0rGhttps://issues.prosody.im/536
MattJAh, fun
MattJThe majority of open fds are UDP sockets "connected" to the DNS server
MattJwhich was down earlier in the week, so I guess that constitutes a bug
Zashhttps://issues.prosody.im/1170 ?
MattJExcept this server is many versions out of date, so probably just needs an upgrade
Ge0rGI remember having a server silently running out of FDs. It sucks.
MattJOh no, it's not out of date, apparently I upgraded it at some point
tuxhas joined
tuxhas joined
MattJZash, so I guess you can take NeedInfo off that issue :)
ZashIs this even 0.10.x?
MattJ0.10.2
ZashMattJ: That change isn't in 0.10.2
MattJAh
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
MattJOk, service should be restored for now
nycohas left
danielhas left
danielhas joined
Ge0rGdid 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
Ge0rGjonas’: message to all admins and reexec
ZashWhy
ZashAnd how
Ge0rGZash: it will close all sockets.
ThibGhas joined
danielhas left
flowGe0rG 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
flowjonas’, 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
Ge0rGflow: feel free to PR against https://issues.prosody.im/536
MattJGe0rG, PR for an external script?
MattJI'll repeat what's already said in the issue: there is no API for asking the OS how many fds you have open
MattJSo file an issue for Linux
ZashI haven't even seen anyhing in the epoll API that tells you how many FDs you are watching
ZashEasy enough with select() since you have to manually add them for every call
jonas’open /proc/self/fd, count number of entries?
ZashBut then you're limited to sizeof(fd_set) * (bits per byte)
Zashjonas’: That's mentioned in a comment in the issue already
jonas’sorry :)
Ge0rGMattJ: the external script could be part of the OS-level packaging and tooling
matlaghas left
matlaghas joined
ZashFile an issue for systemd
MattJTalking about epoll/etc. is besides the point... fds != connections
Ge0rGisn't this all about fds only?
MattJYou suggested select/epoll in comment 6
MattJand I pointed out what I just pointed out (fds != connections) in comment 7
ZashAll this has happened before, and all of it will happen again, and again, and again.
ZashWhat jonas’ said is comment 8
MattJThe only way to correctly implement this is an O(N) loop, run $frequently
ZashCan you get the size of a directory in O(less than n) in Linux?
ZashOr does that just move the O(n) elsewhere?
efrithas joined
Ge0rGMattJ: you are the one bringing up connections all the time.
ZashOr are /proc directory entries too magical for that
Ge0rGZash: opening /proc/self/fd requires... a free fd
ZashDun dun DUN
matlaghas left
matlaghas joined
Ge0rGI wouldn't be surpsised if sending a message to admins would also require a free fd.
Ge0rGor multiple ones.
ZashMight, yes
Ge0rGCan't you just detect EMFILE from any fd you open and trigger an error condition on that?
Ge0rGBTW, this MUC is exceptionally laggy today.
ZashStorage might need a FD to write to eg offline storage or archive
ZashDon't we already?
blablahas left
ZashWow, that is laggy
Ge0rGMattJ: did prosody run out of descriptors again?
ZashBut not now?
Zash.
ZashApparently it is
Zash17:00 now
Zash25s lag
ZashCatching up with something?
Ge0rGxsf@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.
Ge0rGsometimes it's fast, and sometimes it lags. swap disk thrashing?
waqas.
jonas’fun :)
Zash.
Ge0rG.
.
,
-
jonas’fertig ist das mondgesich,.
jonas’fertig ist das mondgesicht
Zashu wut m8?
MattJEverything seems fine to me
jonas’maybe bad internet weather?
Ge0rGdo I need to add xmpp.org to my smokeping?
jonas’do it
Ge0rGall is looking well on the icmp front
Ge0rGit must be a host latency issue.
MattJAh, postgres 100% CPU, user: xmppoke
jonas’nice
MattJ.
MattJ.
waqas.
ZashIs xmpp.net still broken?
ZashLooks liket here are recent results that worked
ZashLooks like there are recent results that worked
MattJ`docker nice`...
jonas’nice
jonas’(pun intended)
Berkhas joined
MattJIt doesn't exist
MattJI wish it did
j.rhas joined
j.rhas joined
j.rhas left
j.rhas joined
SamWhitedhas joined
vanitasvitaehas joined
Zashhas left
guusdkhas left
guusdkhas joined
matlaghas left
matlaghas joined
Berkhas left
efrithas left
Andrew Nenakhovhas left
SamWhitedhas left
SamWhitedhas left
Valerianhas left
SamWhitedjonas’: 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
SamWhitedI'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
SamWhitednot 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
SamWhitedI 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
SamWhitedThat'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
SamWhitedHmm, 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
SamWhitedYah, 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
SamWhitedYou 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
SamWhitedI don't think that's true, these are two different things
SamWhitedIf 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
SamWhitedIf 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
SamWhitedI'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.
SamWhitedAnd 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
SamWhitedI reviewed a few; they were mostly terrible, unidiomatic, and unmaintained.
SamWhitedThey're examples, but not actually something I'd use in prod
SamWhitedAnd 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
SamWhitedMaybe 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
SamWhitedThey 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
SamWhitedYah, 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
SamWhitedI 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
SamWhitedIt 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
SamWhitedSince 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
SamWhitedIt's bad
SamWhitedThat one in particular is more or less unusably bad; there are standard interfaces for doing colors in go which it doesn't implement.
SamWhitedAlso the code just isn't idiomatic
SamWhitedAnd 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
SamWhitedI get that that's a pain, but it still seems worth using an actual standard
SamWhitedEven if it doesn't look as great; YCbCr seemed fine to me personally
blablahas left
SamWhitedActually, 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.
SamWhitedI guess that one's not all that widely used, even if it has been standardized for a while
SamWhitedSo maybe starting from that wouldn't help, I haven't looked at other languages yet though
XSF Discussion - 2018-10-11