00:43:43 hi! 01:07:45 I did some research on this issue: 15316 listen(fd, -1) should give maximum backlog, not minimum 01:07:46 And I still don't understand why we should adapt to this "mistake" (backlog < 0 => maximum backlog). 01:07:46 Can someone please explain to me why it is necessary to change the default (and standard) behavior of the system instead of just fixing the emulation (in lx-brand)? 01:18:15 Even FreeBSD tried to fix this: D31821 Improve POSIX compliance of listen() 01:18:15 https://reviews.freebsd.org/D31821 01:29:17 domag02: I think it's pretty clear that POSIX is not, in 2023, alway the most relevant standard 01:33:01 domag02: The last comment in that FreeBSD review thread is pretty relevant. The POSIX recommendation in this case does not mesh with what software is frequently expecting to occur; most open source software development primarily targets Linux and perhaps a BSD. 01:33:03 jclulow: but it is not even compatible with LSB (Linux Standards Base) 01:33:40 Can you give a reference for that behaviour? 01:34:12 jclulow: for what OS? 01:34:20 "not even compatible with LSB" 01:34:30 jclulow: OK 01:34:40 Are you saying we are not moving towards the Linux behaviour? I had thought that was the point of the bug 01:36:39 jclulow: *Linux is not compatible with LSB (in regard of listen() behaviour) 01:36:50 It feels, perhaps, like LSB is not that relevant either then! 01:37:25 It doesn't really matter what's in a standard if the software people want to run works another way, unfortunately. 01:38:09 https://www.illumos.org/issues/15316 suggests we are at odds with Linux and two popular BSDs 01:38:13 → BUG 15316: listen(fd, -1) should give maximum backlog, not minimum (New) | https://code.illumos.org/c/illumos-gate/+/2598 01:47:56 jclulow: to me it looks more like a userspace programming error and not the "new standard", because there is also a standard (and portable) way of doing this with INT_MAX as backlog 01:49:45 The problem with things like this is that you have to prioritise how you spend the rest of your life. I am not personally interested in POSIX or any other standard _for its own sake_, but where it is a helpful tool, we're on board. If the prevailing wind is a behaviour that is not _exactly_ what the standard says, but frankly not actually outlawed by wishy-washy language, helps more software 01:49:47 work without patches, then I think it is worth considering. 01:50:18 We also haven't landed the patch, we're looking at it and what impact it might have. 01:50:59 You have to understand though, that if you do something intentionally different from both Linux and Free/Open/NetBSD, that you're signing up for a crusade of open source letter writing forever to try and get small patches into each new body of software you want to use. 01:51:32 I have written a lot of letters! I will no doubt write many more. It is exhausting, and sometimes it is easier to fix things on our end where it will have otherwise little to no impact on people. 01:58:57 jclulow: NetBSD has implemented the POSIX behavior. 01:58:57 See here: https://github.com/NetBSD/src/blob/trunk/sys/kern/uipc_socket.c#L656 14:25:22 @tsoome_ "...that page turned" ===> gcc10-by-default? (Sorry, LimeChat's history is low, and I *think* that's what you meant by consulting log.omnios.org...) 15:37:13 yes, gcc10:) 15:48:40 [illumos-gate] 15283 head: remove pragma ident -- Toomas Soome