01:17 < bridge> <Robyt3> I'll probably just make the PR when I'm finished. I don't want to wait forever for SDL to get fixed. Without the SDL update, we just don't get the candidate window yet, but all the text input improvements and IME text composition are already good enough for now.
01:17 < bridge> <Robyt3> https://cdn.discordapp.com/attachments/293493549758939136/1097662149259698176/image.png
01:18 < bridge> <Robyt3> ^ @TsFreddie soon
06:46 < bridge> <Jupstar ✪> Does the candidate window imply they can use it in Fullscreen if it is rendered by us?
08:01 < bridge> <TsFreddie> I don't think rendering the candidate window would ever be possible
08:01 < bridge> <TsFreddie> tons of third-party IMEs just draw their own windows with however methods they want anyway.
08:04 < bridge> <TsFreddie> what did they do to SDL again
08:08 < bridge> <Jupstar ✪> But isn't that better for us
08:08 < bridge> <Jupstar ✪> Drawing our own
08:08 < bridge> <TsFreddie> we have to draw our own
08:08 < bridge> <TsFreddie> yes
08:09 < bridge> <TsFreddie> I thought you mean drawing their window in our own renderer
08:10 < bridge> <TsFreddie> there is no way to get the IME's candidate window as a texture AFAIK
08:10 < bridge> <TsFreddie> also some IME uses the number differently. but that's pretty rare I suppose.
08:35 < ChillerDragon> there is no logrottate or max txt file size code i could reuse in ddnet code base right?
08:39 < bridge> <TsFreddie> hi chiller
08:40 < ChillerDragon> o/
09:11 < bridge> <T.Charlie> cool!!!!!
09:23 < bridge> <deen> I don't think so, we just restart servers daily
09:42 < ChillerDragon> yea took a similar approach for it :) im working on history for my client and instead of append on command i just overwrite on shutdown that also works as a cap
10:55 < bridge> <Ewan> Sup Fred
11:05 < bridge> <Ryozuki> https://blog.rust-lang.org/inside-rust/2023/04/17/1.69.0-prerelease.html
11:05 < bridge> <Ryozuki> 69 nice
11:10 < bridge> <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1097811484295307264/image.png
11:21 < bridge> <ReiTW> when do they implement raw sockets
11:22 < bridge> <Ryozuki> > In Unix-like systems, everything is a file, including sockets, so the way to get raw access to a socket would be to convert it to a file descriptor with AsRawFd 18. From what I understand, Windows distinguishes files and sockets, so there are separate AsRawHandle 2 and AsRawSocket 13 traits for Windows. In both cases the interface is fairly low-level, but Rust is fairly conservative about what goes in its standard library, so higher level abstrac
11:22 < bridge> <Ryozuki> https://doc.rust-lang.org/nightly/std/os/fd/trait.AsRawFd.html
11:23 < bridge> <Ryozuki> use a crate
11:24 < bridge> <Ryozuki> i dont see many libs actually
11:24 < bridge> <Ryozuki> so this must be not rly useful
11:25 < bridge> <ReiTW> it is when u want to do lower level stuff
11:25 < bridge> <Ryozuki> i doubt
11:25 < bridge> <Ryozuki> a udp or a tcp socket work
11:25 < bridge> <Ryozuki> what is it u want to do
11:25 < bridge> <ReiTW> what if I wanna work with layer2, eg doing arp stuff
11:25 < bridge> <ReiTW> one thing for example I did in C that I wanted to reproduce in Rust is WoL
11:26 < bridge> <Ryozuki> oh there exists a library
11:26 < bridge> <Ryozuki> https://crates.io/crates/socket2
11:26 < bridge> <Ryozuki> 80M downloads
11:26 < bridge> <ReiTW> obv I could do a udp socket but in C I only had a layer2 header then the magic packet
11:26 < bridge> <Ryozuki> there u go
11:26 < bridge> <ReiTW> oh
11:27 < bridge> <Ryozuki> > This crate provides as direct as possible access to the system's functionality for sockets, this means little effort to provide cross-platform utilities. It is up to the user to know how to use sockets when using this crate. If you don't know how to create a socket using libc/system calls then this crate is not for you. Most, if not all, functions directly relate to the equivalent system call with no error handling applied, so no handling errors 
11:27 < bridge> <Ryozuki> wtf
11:27 < bridge> <Ryozuki> is github down
11:28 < bridge> <ReiTW> no
11:28 < bridge> <Ryozuki> wanted to check this https://github.com/libpnet/libpnet
11:28 < bridge> <Ryozuki> i get 500
11:28 < bridge> <Jupstar ✪> M$
11:28 < bridge> <ReiTW> ah it lags af
11:28 < bridge> <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1097815843678716004/image.png
11:28 < bridge> <Ryozuki> anyway u have the library
11:28 < bridge> <ReiTW> yes github is ded
11:28 < bridge> <Jupstar ✪> I also have more trouble with it lately
11:29 < bridge> <Jupstar ✪> Working for me
11:29 < bridge> <Jupstar ✪> Nobod
11:29 < bridge> <Jupstar ✪> Nobos
11:29 < bridge> <ReiTW> yes it's fixed now
11:29 < bridge> <Jupstar ✪> Xd
11:31 < bridge> <Ryozuki> https://www.githubstatus.com/
11:43 < bridge> <heinrich5991> if you like numbers, you forgot that it's releasing on 4-20
11:44 < bridge> <Ryozuki> lmao
11:44 < bridge> <Jupstar ✪> At 11:44
11:48 < bridge> <Cellegen | RiH> hmmm, maybe I shouldn't force pull into my repo when this is outaged :troll:
11:49 < bridge> <Cellegen | RiH> hmmm, maybe I shouldn't force pull from my repo when this is outaged :troll:
14:03 < bridge> <Ryozuki> any LUKS user?
14:03 < bridge> <Ryozuki> https://mjg59.dreamwidth.org/66429.html
14:03 < bridge> <Ryozuki> PSA: upgrade your LUKS key derivation function
14:04 < bridge> <heinrich5991> my takeaway was: use a secure password
14:04 < bridge> <heinrich5991> e.g. generate it using https://en.wikipedia.org/wiki/Diceware
14:18 < bridge> <Ryozuki> in the blog it says this tho "His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced, and we should be transitioning to even more secure passphrases."
14:56 < bridge> <Ryozuki> https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats
14:56 < bridge> <Ryozuki> https://www.phoronix.com/news/FSF-Slams-Google-JPEG-XL
14:57 < bridge> <Voxel> what the hell is jpeg-xl
14:58 < bridge> <Voxel> and why are these guys acting like a human right was broken
14:58 < bridge> <Ryozuki> dude
14:58 < bridge> <Ryozuki> its hilarious u dont see the issue
14:59 < bridge> <Ryozuki> jpeg-xl is a new format, like avif
14:59 < bridge> <Voxel> wait what
14:59 < bridge> <Ryozuki> https://jpeg.org/jpegxl/
14:59 < bridge> <Ryozuki> @Voxel jpeg itself is a image format optimized for web images
15:00 < bridge> <Ryozuki> webs want images to compress efficiently, even if not lossly
15:00 < bridge> <Ryozuki> jpeg-xl is an improvement
15:00 < bridge> <Ryozuki> like avif
15:00 < bridge> <Ryozuki> but avif is patented by google
15:00 < bridge> <Ryozuki> google supported jpeg-xl and avif
15:00 < bridge> <Ryozuki> google removed jpeg-xl support
15:00 < bridge> <Voxel> damn
15:01 < bridge> <Learath2> But avif has hot marketing material
15:01 < bridge> <Jupstar ✪> I wonder if browsers will ever drop support for anything or will just bloat more and more
15:02 < bridge> <Ryozuki> > AVIF encoders need about 100 times as much time to obtain comparable compression to JPEG XL; at a more practical encode speed (say 2-3 times slower than JPEG XL at default effort), AVIF obtains 10 to 15% worse compression than JPEG XL; at the same encode speed, AVIF is not better or even somewhat worse than MozJPEG
15:03 < bridge> <Learath2> But google likes it
15:03 < bridge> <Ryozuki> https://cloudinary.com/blog/the-case-for-jpeg-xl
15:03 < bridge> <Ryozuki> yeah
15:03 < bridge> <Ryozuki> @Voxel the problem here is google has massive power in steering the web
15:03 < bridge> <Ryozuki> and they dont let users choose
15:03 < bridge> <Ryozuki> read the fsf article
15:04 < bridge> <Jupstar ✪> Why would encode speed matter
15:04 < bridge> <Jupstar ✪> Only decompress matters
15:04 < bridge> <Ewan> https://youtu.be/9sJUDx7iEJw
15:05 < bridge> <heinrich5991> for non-static images
15:09 < bridge> <Jupstar ✪> Why would it matter for them
15:10 < bridge> <Jupstar ✪> U mean when u built a image on server?
15:10 < bridge> <Learath2> Google literally killed off edge by spam breaking youtube to the point where microsoft didn’t feel like investing anymore, absolute demon behaviour
15:10 < bridge> <heinrich5991> yes
15:11 < bridge> <Jupstar ✪> Mh ok
15:11 < bridge> <Learath2> Why not? I regularly export hundreds of jpegs at a time when I return from vacations, just because it’s O(1) doesn’t mean it’s not annoying
15:11 < bridge> <Jupstar ✪> Because 99% of the time u decode images
15:12 < bridge> <Jupstar ✪> The encoded somehow cached
15:12 < bridge> <Jupstar ✪> Esp browsers
15:12 < bridge> <Learath2> And at that 1 percent of time when I encode them I’d like them to be snappy too, if it doesn’t cost decode performance
15:12 < bridge> <Jupstar ✪> Yes that's why decode is the main benchmark here
15:13 < bridge> <Jupstar ✪> If it's 10% faster. Then 15% slower decode sounds sane to me
15:13 < bridge> <Learath2> Assuming decode speeds are the same, (because if they weren’t people would be using that argument instead) I’ll take improvements in encode speed as positives
15:13 < bridge> <heinrich5991> I found the property of being able to losslessly compress JPGs furtherly cool
15:14 < bridge> <Learath2> The progressive loading also sounded enjoyable
15:14 < bridge> <Jupstar ✪> Then for sure
15:15 < bridge> <Jupstar ✪> Is cool indeed. But even there it has to compare against a fast lossless format I'd say
15:15 < bridge> <Jupstar ✪> Or does it simply implement 2 algorithms
15:15 < bridge> <Ryozuki> > We looked at six aspects of JPEG XL where it brings significant benefits over existing image formats:
15:15 < bridge> <Ryozuki> > 
15:16 < bridge> <Ryozuki> >     Lossless JPEG recompression
15:16 < bridge> <Ryozuki> >     Progressive decoding
15:16 < bridge> <Ryozuki> >     Lossless compression performance
15:16 < bridge> <Ryozuki> >     Lossy compression performance
15:16 < bridge> <Ryozuki> >     Deployable encoder
15:16 < bridge> <Ryozuki> >     Works across the workflow
15:25 < bridge> <Voxel> lmao i forgot to say
15:25 < bridge> <Voxel> first thing i did before going to work was debug my code
15:25 < bridge> <Voxel> heinrich saw it live
15:26 < bridge> <Voxel> first thing i did when i woke up and before going to work was debug my code
15:26 < bridge> <Jupstar ✪> Are u a pair with him?
15:26 < bridge> <Ryozuki> shame of u
15:26 < bridge> <Ryozuki> use free software
15:26 < bridge> <Ryozuki> https://framatube.org/w/fd71e37c-91e8-47e6-be10-411ef908ff4b
15:26 < bridge> <Ewan> lol my bad
15:26 < bridge> <Jupstar ✪> Lmao
15:27 < bridge> <Voxel> :greenthing:
15:29 < bridge> <Ryozuki> peertube is agpl-3 licenses
15:29 < bridge> <Ryozuki> chad
15:29 < bridge> <Ryozuki> peertube is agpl-3 licensed
15:29 < bridge> <Ryozuki> chads
15:32 < bridge> <Jupstar ✪> https://avif.io/blog/comparisons/avif-vs-jpegxl/
15:32 < bridge> <Jupstar ✪> 
15:32 < bridge> <Jupstar ✪> Is this a troll? It sounds like jpegxl is better in anything and their conclusion is that they have more marketing, or what? XD
15:34 < bridge> <Ryozuki> @Jupeyy_Keks its google marketing
15:34 < bridge> <Ryozuki> i hope
15:34 < bridge> <Ryozuki> firefox keeps support
15:34 < bridge> <Ryozuki> and it fragments the web
15:35 < bridge> <Ryozuki> the thing is
15:35 < bridge> <Jupstar ✪> It's just weird that they are like "the competitor is much better, please buy our product" xD
15:35 < bridge> <Ryozuki> mozilla depends a lot on google for funding
15:35 < bridge> <Ryozuki> google pays mozzila to have google as primary search engine
15:36 < bridge> <Jupstar ✪> Yeah
15:36 < bridge> <Jupstar ✪> But tbf most other search engines are still light-years away xd
15:36 < bridge> <Ryozuki> https://www.phoronix.com/forums/forum/software/desktop-linux/1370271-mozilla-comes-out-neutral-on-jpeg-xl-image-format-support
15:36 < bridge> <Ryozuki> > "Our market share is so low whatever we decide is unlikely to change the status of JPEG-XL on the web".
15:36 < bridge> <Ryozuki> XD
15:36 < bridge> <Ryozuki> > Translating marketing speech to human language:
15:36 < bridge> <Ryozuki> > "Our market share is so low whatever we decide is unlikely to change the status of JPEG-XL on the web".
15:37 < bridge> <heinrich5991> > JPEG XL doesn't perform well with its appeal, with low-fidelity images looking worse, with more noticeable artifacts in heavily compressed images.
15:37 < bridge> <heinrich5991> it's not better in everything, according to the linked page
15:38 < bridge> <heinrich5991> (seems to be better in most mentioned things though)
15:38 < bridge> <Jupstar ✪> Yeah also I'd say lofi isn't the most often use case xd
15:39 < bridge> <Ryozuki> the most often use case is blog banners
15:39 < bridge> <Ryozuki> xd
15:39 < bridge> <Ryozuki> or twitter images
15:40 < bridge> <Jupstar ✪> Instagram
16:48 < bridge> <Ryozuki> @Jupeyy_Keks lmao
16:48 < bridge> <Ryozuki> they updated github
16:48 < bridge> <Jupstar ✪> Design ?
16:49 < bridge> <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1097896595355357255/image.png
16:50 < bridge> <Ryozuki> i guess space  is better used
16:50 < bridge> <heinrich5991> not visible to me yet
16:52 < bridge> <Ryozuki> this is how gh may look in the future
16:52 < bridge> <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1097897501081751732/image.png
16:52 < bridge> <Jupstar ✪> Looks like mobile
16:52 < bridge> <Jupstar ✪> But maybe cool once u get used to it
16:52 < bridge> <Ryozuki> if u set on the global redesign preview mode
17:19 < bridge> <Jupstar ✪> i dont have it
17:19 < bridge> <Jupstar ✪> i only have navigation redesign preview
17:19 < bridge> <Ryozuki> yeah
17:19 < bridge> <Ryozuki> the change is gradual i guess
17:20 < bridge> <Jupstar ✪> ah
17:20 < bridge> <Jupstar ✪> in combination with "New Code Search and Code View"
17:20 < bridge> <Jupstar ✪> now it looks like in urs