XSF Discussion - 2018-10-11

ping

pong

peng

björn?

The 35c3 voucher system has started, did you get in touch with them to get some?

Link Mauve: this should be for SCAM team, right?

Ah, maybe.

Scam or not maybe somebody can send something, so we're not too late

@SCAM: mailto:35c3-tickets@cccv.de ✏

Ge0rG, Link Mauve, ^ I don’t konw if SCAM has a MUC or something. forward it to them.

scam@muc.xmpp.org

(something something too many tabs something)

:)

hah, relevant backlog in that muc

Exactly

yep ;-)

who chairs? who minutes?

Go for it

I'll chair if someone else can minute

I'll do afterwards

thx

Ok

0) Role call: nyco, guusdk and myself

1) Topics for agenda

Anyone have anything not on Trello?

No

nope

2) Decisions: board priorities

last time we talked prios, didn't have time to talk executive

oh ok

Didn't we decide on this already?

according to the minutes, we did not decide (we were not meant to)

Gah, browser with Trello and minutes just crashed, one moment

we agreed we would not take decisions for the next board

Right

So are we done with this for now?

that's my feeling

Nyco, didn't you offer to draft a nice recommendation for next board?

thx

Moving on...

I'm not trying to make nyco donor, btw. Though he volunteered

Donor/do it

that's fine, I'm happy to contribute this

3) Commitment for the week (ha!) ahead: search for new ED

(which week? ;-) )

I don't think we should be expecting Martin back before the end of the term

and this was assigned to him

Nope, we already have one

there is a subject with Peter on sponsoring as well, right?

modifying the bylaws need some work I guess, like validate the changes by a lawyer?

guusdk, added to Trello

Tx

5) Discussion: Change board member tenure

Did we come to some decision on this?

I don't believe that there's consensus to change anything here.

Leave as-is?

I'll archive the card then

agree, I feel we don't want to change

Ok, that's cleared up a few things in Trello

We're left with our two long-running themes of the year (fundraising/financing, and ED replacement), and one new action item (call with Peter)

6) AOB?

I have none

Board/council elections process was started by the Secretary

Oh, wasn't aware of that

Please find candidates and/or apply on wiki

Shall do

https://wiki.xmpp.org/web/Board_and_Council_Elections_2018

See mail sent on October 1

@SCAM can/should we tweet that?

Doesn't really fall under SCAM, does it? There's nothing meetup-related

nyco: good idea

But it should be tweeted nonetheless

+1

oh commteam

Yeah, sorry, I realised it was probably just a typo after I wrote my message :)

we also should tweet every call for membership

Ok, I think we're done then

7) Next meeting

+1 week

+1

+1

Ok

8) The End

Thanks all

thx all!

Thanks

Aha

I think I found what's up with xmpp.org

Well, the XMPP service anyway

Currently holds 1020 open fds, limit is 1024

It uses select???

Le Sigh.

ulimit

Oh

https://issues.prosody.im/536

Ah, fun

The majority of open fds are UDP sockets "connected" to the DNS server

which was down earlier in the week, so I guess that constitutes a bug

https://issues.prosody.im/1170 ?

Except this server is many versions out of date, so probably just needs an upgrade

I remember having a server silently running out of FDs. It sucks.

Oh no, it's not out of date, apparently I upgraded it at some point

Zash, so I guess you can take NeedInfo off that issue :)

Is this even 0.10.x?

0.10.2

MattJ: That change isn't in 0.10.2

Ah

Ok, service should be restored for now

did you throw in some more sockets?

prosody should just re-exec itself when it runs out of sockets /s

jonas’: message to all admins and reexec

Why

And how

Zash: it will close all sockets.

Ge0rG why not simply monitor the open fd externally and send an (XMPP) message?

*open fd count

Ge0rG, let me tell you about my botnet opening 65535 TCP connections to your prosody instance :>

flow, "simply" and "monitor" and "prosody" in a single statement is daring

"fd count" is painful as well

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

flow, picking the right process to monitor isn’t easy either

flow: feel free to PR against https://issues.prosody.im/536

Ge0rG, PR for an external script?

I'll repeat what's already said in the issue: there is no API for asking the OS how many fds you have open

So file an issue for Linux

I haven't even seen anyhing in the epoll API that tells you how many FDs you are watching

Easy enough with select() since you have to manually add them for every call

open /proc/self/fd, count number of entries?

But then you're limited to sizeof(fd_set) * (bits per byte)

jonas’: That's mentioned in a comment in the issue already

sorry :)

MattJ: the external script could be part of the OS-level packaging and tooling

File an issue for systemd

Talking about epoll/etc. is besides the point... fds != connections

isn't this all about fds only?

You suggested select/epoll in comment 6

and I pointed out what I just pointed out (fds != connections) in comment 7

All this has happened before, and all of it will happen again, and again, and again.

What jonas’ said is comment 8

The only way to correctly implement this is an O(N) loop, run $frequently

Can you get the size of a directory in O(less than n) in Linux?

Or does that just move the O(n) elsewhere?

MattJ: you are the one bringing up connections all the time.

Or are /proc directory entries too magical for that

Zash: opening /proc/self/fd requires... a free fd

Dun dun DUN

I wouldn't be surpsised if sending a message to admins would also require a free fd.

or multiple ones.

Might, yes

Can't you just detect EMFILE from any fd you open and trigger an error condition on that?

BTW, this MUC is exceptionally laggy today.

Storage might need a FD to write to eg offline storage or archive

Don't we already?

Wow, that is laggy

MattJ: did prosody run out of descriptors again?

But not now?

.

Apparently it is

17:00 now

25s lag

Catching up with something?

xsf@muc.xmpp.org did not respond to ping after 10s: timeout

ping

wfm

very fast from here

.

sometimes it's fast, and sometimes it lags. swap disk thrashing?

.

fun :)

.

. . , -

fertig ist das mondgesicht ✏

u wut m8?

Everything seems fine to me

maybe bad internet weather?

do I need to add xmpp.org to my smokeping?

do it

all is looking well on the icmp front

it must be a host latency issue.

Ah, postgres 100% CPU, user: xmppoke

nice

.

.

.

Is xmpp.net still broken?

Looks like there are recent results that worked ✏

`docker nice`...

nice

(pun intended)

It doesn't exist

I wish it did

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

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

not just some random persons personal project that's not used anywhere

right

so, what we did on top of YCbCr is essentially what HSLuv does on top of CIE XYZ, but worse

so it’s a home-brew solution either way

except that HSLuv gives better results

I didn't remember you making changes to YCbCr, what did you do on top of it?

the algorithm to determine CbCr based on the angle

or rather, based on the 16 bit input extracted from the hash

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

that’s what HSLuv does on top of XYZ anyways

but the results are much more uniform than what we had with YCbCr

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

http://www.hsluv.org/math/

oh, it works on top of CIE LUV LCh, not XYZ

not sure where I got the XYZ from

it is really pretty much exactly what we did with YCbCr: use Hue as angle, cast a ray to the border, take value

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

You couldn't just pick a color from an eisting CIE LUV implementation, as far as I can tell from this

so, old XEP-0392 was just an entirely new color space which can be defined as a transformation of YCbCr; that’s wordplay

I don't think that's true, these are two different things

If I had the set of all possible colors in YCbCr I could do you algorithm and get colors in that set (I think?)

no

If I have the set of all colors in CIE LUV I can't do 0392 with that, I have to implement HSLuv first

no wait, I don’t understand what you’re saying

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.

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

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

the C one, too

I reviewed a few; they were mostly terrible, unidiomatic, and unmaintained.

They're examples, but not actually something I'd use in prod

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

maybe

however, the results with YCbCr are not as nice as HSLuv

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)?

that would make 0392 unnecessarily long

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

the difference is in the uniformity of brightness

lemme grab you a screenshot

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?

not really, unless you do exactly what HSLuv does

maybe on top of something else

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

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

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

Since I'd have to do that to implement it anyways

the golang implementation doesn’t look too bad to me, but I don’t know lots of go either way

It's bad

That one in particular is more or less unusably bad; there are standard interfaces for doing colors in go which it doesn't implement.

Also the code just isn't idiomatic

And is impossible to follow or reason about because of the way they've defined it as transformations through multiple other colorspaces

color spaces are all a mess, unless you go to the photometric ones

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

I get that that's a pain, but it still seems worth using an actual standard

Even if it doesn't look as great; YCbCr seemed fine to me personally

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

I’m not surprised.

I guess that one's not all that widely used, even if it has been standardized for a while

So maybe starting from that wouldn't help, I haven't looked at other languages yet though