2026/03/29

Newest at the top

2026-03-29 23:10:11 +0200 <glguy> I also worked in a movie theater back when people still lined up to see movies on the big screen and lines could get quite long
2026-03-29 23:09:42 +0200 <EvanR> yeah just assume the customer is baseline evil and you won't be disappointed
2026-03-29 23:09:23 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) koala_man
2026-03-29 23:08:58 +0200 <tomsmeding> (my supermarket cashier experience is from when I was like 15 and didn't know shit)
2026-03-29 23:08:57 +0200 <glguy> I worked at a computer store in the age of mail in rebates. Every sunday lines went to the back of the store as people can in to get their free-after-rebate stuff
2026-03-29 23:08:43 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-29 23:08:27 +0200 <glguy> When I worked people who'd been waiting in a long line behaved at least a little differently from those who hadn't been waiting long
2026-03-29 23:08:17 +0200 <monochrom> Pretty sure the capitalist supermarket managers have found the sweet spot of the right queue length pressure to balance between "motivation to work" and error rate. :)
2026-03-29 23:07:37 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 268 seconds)
2026-03-29 23:07:14 +0200 <EvanR> having worked black friday, from my perspective it wasn't particularly different from a normal busy day, since I can't tell the diff between 5 people in my line vs 500
2026-03-29 23:06:06 +0200 <EvanR> standing there with nothing to do is the worst though
2026-03-29 23:05:34 +0200 <tomsmeding> putting pressure on cashier workers is indirectly also a bit mean to the supermarket, as it results in more mistakes and more missed (i.e. stolen) products, but likely the effect on the cashiers is bigger, yes
2026-03-29 23:04:18 +0200 <monochrom> And now that I think about it, even those reasons are intended to be mean (to customers in the 1st case, employees in the 2nd case).
2026-03-29 23:01:39 +0200Guest96(~Guest62@p200300ca8f23fa0023c431aeeea1b74f.dip0.t-ipconnect.de) (Quit: Client closed)
2026-03-29 22:59:29 +0200 <monochrom> In the brick-and-mortor retail world, there are only two reasons to do that (long customer queue). One is to create hype ("oh look at how many people are dying to buy our product!"). The other is in supermarkets putting pressure on cashier workers.
2026-03-29 22:57:51 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-03-29 22:57:20 +0200 <monochrom> listen(a number in the order of thousands) is simply mean.
2026-03-29 22:53:22 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-29 22:42:57 +0200merijn(~merijn@62.45.136.136) (Ping timeout: 269 seconds)
2026-03-29 22:37:58 +0200merijn(~merijn@62.45.136.136) merijn
2026-03-29 22:35:19 +0200pavonia(~user@user/siracusa) siracusa
2026-03-29 22:34:12 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) koala_man
2026-03-29 22:33:27 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) (Read error: Connection reset by peer)
2026-03-29 22:33:06 +0200srazkvt(~sarah@user/srazkvt) (Quit: Konversation terminated!)
2026-03-29 22:30:55 +0200machinedgod(~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 264 seconds)
2026-03-29 22:30:29 +0200 <TMA> that might be a problem
2026-03-29 22:29:04 +0200 <tomsmeding> through this function https://hackage-content.haskell.org/package/streaming-commons-0.2.3.1/docs/src/Data.Streaming.Netw…
2026-03-29 22:28:58 +0200 <tomsmeding> TMA: following the call chain, warp seems to pass 2048 there
2026-03-29 22:28:11 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 244 seconds)
2026-03-29 22:27:19 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-03-29 22:26:48 +0200emmanuelux(~em@user/emmanuelux) emmanuelux
2026-03-29 22:25:08 +0200 <TMA> [exa]: there is a parameter to listen(2) that limits how many unaccepted connections are waiting. setting it to 5 or 3 is fine for the normal case of acepting often
2026-03-29 22:23:42 +0200emmanuelux(~em@user/emmanuelux) (Read error: Connection reset by peer)
2026-03-29 22:22:36 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-29 22:21:50 +0200takuan(~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 256 seconds)
2026-03-29 22:19:28 +0200jreicher(~joelr@user/jreicher) jreicher
2026-03-29 22:17:47 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) marinelli
2026-03-29 22:17:27 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection)
2026-03-29 22:17:17 +0200jmcantrell_(~weechat@user/jmcantrell) jmcantrell
2026-03-29 22:13:11 +0200 <[exa]> nah, you still need a state machine there, doesn't help.
2026-03-29 22:11:51 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds)
2026-03-29 22:07:15 +0200merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-29 22:05:42 +0200 <tomsmeding> I don't know how it works but a friend does and he's happy for reasons complementary to what you seem to not like in tcp
2026-03-29 22:05:22 +0200 <tomsmeding> then I bet you're happier with QUIC
2026-03-29 22:04:40 +0200 <[exa]> :D
2026-03-29 22:04:38 +0200 <[exa]> in other news I'm not a great fan of tcp
2026-03-29 22:04:19 +0200 <tomsmeding> yes
2026-03-29 22:04:14 +0200 <[exa]> "not accepted" means "queued forever in the OS" which might be worse
2026-03-29 22:04:02 +0200 <tomsmeding> hm
2026-03-29 22:03:55 +0200 <tomsmeding> with the downside being that connections that go over the limit are accepted and then dropped instead of not accepted