Time Nick Message 02:06 Confines Yo user333_ 02:06 Confines Finally got back from the work trip, nice attack lmao 02:08 Confines Finally got around to adding a packet size limiter, I don't have enough ram to serve massive packets 02:34 user333_ oh hi Confines 02:41 user333_ ... 02:45 user333_ he just timed out 03:05 Confines I'm back 03:08 Confines Just finished bringing the backend back from the dead and adding some much needed security measures 03:14 user333_ took you long enough, it was offline for almost 24h 03:15 Confines I was on a work trip out of state 03:19 user333_ i was setting up my new PC :P 03:20 user333_ anyway, that's twice i crashed your backend 03:23 Confines Yeah, although both times the actual backend was fine, it just ran out of memory, either way that should be fixed now 03:23 user333_ time to find more exploits! 03:24 Confines Please do!@ 03:24 user333_ also remove the 28,000 accounts a friend registered with a script :> 03:24 Confines Already did 03:24 Confines Closer to 34,000 03:24 user333_ oh wow 03:24 Confines Still only took 100 kb 03:25 user333_ also did you find any buggy ones? i registered a few with newlines/carriage returns/random unicode characters/escapes 03:31 user333_ yay my new PC can run luanti with (almost) all shaders on 03:31 [MatrxMT] reject shaders, embrace 1000 render distance 03:31 user333_ nah 03:32 user333_ i have a (relatively) good PC now, 6 cores/12 threads @3.5ish GHz, 16GB DDR4, 512GB SSD, dualbooting windows 11 23H2 and ubuntu 24.04.3 03:34 user333_ and some AMD GPU, lucky it wasn't NVIDIA, i hear their drivers are a pain to install on linux 03:34 [MatrxMT] things have gotten better for nvidia lately, but, yes 03:34 [MatrxMT] you have to have a lot of money lying around to buy their late model GPUs though 03:35 user333_ this was some mini PC from amazon for like $500, very good price/specs ratio 03:36 user333_ it's about ~2x larger than my RPi5+it's case 03:41 Confines I'm so happy for you! 03:41 Confines Now you can attack my backend with even more speed! 03:41 user333_ now the fun part... transferring files from my RPi5 to my new PC 03:41 user333_ using SFTP is giving me like ~30s of lag here though 03:42 Confines Do you not have a usb stick 03:42 user333_ you sound sarcastic :P 03:42 Confines Nah 03:43 user333_ i have a 128GB usb drive and a 1TB external hard drive... + some cheap 4GB USB drives that will corrupt if you touch them 03:43 user333_ lucky the -l option for scp exists 03:44 Confines Nice 03:45 user333_ i'm using SFTP bc it's more convenient .-. 03:45 user333_ il just let it run overnight and suffer the lag while i copy over my important stuff (totally not pirated games) 03:47 Confines I love pirated games! 03:47 user333_ so do i! i have (almost) every half-life and portal games, and a few SNES ROMS 03:48 user333_ *nintendo and valve knock on my door* 03:48 Confines nintendo can smb 03:49 user333_ the SNES roms don't require a network connection to work so gl nintendo :P 03:55 user333_ anyway im still waiting for an IRC channel :P 04:28 Confines I'll do that soon, you've been keeping me busy on less fun things lol 04:33 user333_ happy to help 04:41 user333_ 'Request entity too large\n' looks like you fixed it 04:44 user333_ now to find an SQL injection vulnerability 04:48 Confines SQL injection hasn't been a thing since I made the backend 04:48 Confines I was awake enough to make sure I had that 04:48 Confines when I made the backend 04:54 user333_ oh good lol 04:54 user333_ i'm no cybersecurity expert but it lgtm (for now :P) 04:58 user333_ i still have a few ideas to crash it but they are closer to a DDoS than an exploit 05:04 Confines Please give it all you got 05:22 repetitivestrai- https://github.com/luanti-org/luanti/issues/16633 05:23 repetitivestrain https://github.com/luanti-org/luanti/issues/16633 since this proposal surfaces every so often and the ergonomics of configuring mineclonia's lua map generator are abysmal as it stands, why can't num_emerge_threads simply be fixed to one for the built-in map generators, which do not support multiple emerge threads, and configured to 0 or some other suitable default on singlenode 05:26 repetitivestrain e.g.: https://github.com/luanti-org/luanti/issues/10606, https://github.com/luanti-org/luanti/issues/15630 05:26 repetitivestrain and i receive the impression that it was 0 by default some years ago 08:43 sfan5 repetitivestrain: wouldn't just setting this in your game's minetest.conf work? 08:44 repetitivestrain sfan5: unfortunately not, because we also support the built-in mapgens 08:45 repetitivestrain and i'm not sure whether modifying the option from lua would be possible, but it's still out of the question as it would overwrite players' minetest.confs on singleplayer 08:46 sfan5 set_mapgen_setting does not work for this, no 08:47 repetitivestrain yeah, i've already attempted this, but i was speaking of altering core.settings 12:11 sfan5 repetitivestrain: good news https://github.com/luanti-org/luanti/pull/16634 12:11 repetitivestrain sfan5: much appreciated, thank you! 12:33 repetitivestrain sfan: i think the upper limit should be more conservative by default, as each lua environment started must by nature redundantly allocate memory for a great amount of information, voxelmanips, and cid and param2 arrays, which can amount to up to 500-700MB/thread, and defaulting to a maximum of 20 threads might unduly stress the system for memory 12:33 repetitivestrain particularly on recent laptops with 16+ thread processors but only 16 gigabytes of ram that must be shared with other programs 13:03 sfan5 what do you suggest 13:04 repetitivestrain 8, i think 13:04 repetitivestrain that's what i use on my server (which has 64 cores) and produces a maximum rss of 6 gigabytes without any loaded blocks and 8 otherwise 13:05 repetitivestrain otherwise with 1-2 players online* 13:07 sfan5 6GB for 8 threads sounds like a lot 13:07 repetitivestrain there's also the main thread and one async environment thread which share the same data 13:08 [MatrxMT] is this the mcla mapgen with redundant data or one of the C++ mapgens? 13:08 sfan5 hold on 13:09 sfan5 !c (5*16)**4 * 4 / (1024*1024) 13:09 MinetestBot 156.25 13:09 repetitivestrain Blockhead256: with the lua map generator, yes 13:12 sfan5 wait i calculated wrong 13:12 sfan5 !c (5*16)**3 * 4 / (1024*1024) 13:12 MinetestBot 1.953125 13:13 repetitivestrain well that's not exactly accurate, since lua arrays are composed of 8 byte doubles 13:13 sfan5 even by a conservative estimate one copy of a chunk is <10MB 13:13 sfan5 how much do you store that you arrive at 700MB 13:15 repetitivestrain three arrays of 80x512x80 data that amount to 75 megabytes, a 50 mb biome table, 75 megabytes of loaded schematics, i think, and hundreds of megabytes of jit code cache 13:15 sfan5 !c 3*75+50+75 13:15 MinetestBot 350 13:16 repetitivestrain you can reduce maxmcode to the default 64k and observe performance decline as you move between areas with different terrain characteristics but also maximum rss decline by a few hundred megabytes per thread 13:23 repetitivestrain right, i also overlooked the generated biome array 13:24 repetitivestrain which is as large as the mapblock itself and is also serialized and reported to the main thread as a gennotify 13:28 repetitivestrain hmm, it's actually vmanip:get_data and vmanip:get_param2_data that allocate nearly 128 mb 13:30 repetitivestrain -> Pre-on_generated.: 29 MB (+ 2) -> on_generated.: 157 MB (+ 128) -> Biome generation.: 158 MB (+ 1) -> Terrain generation.: 197 MB (+ 39) -> Biome encoding.: 197 MB (+ 0) -> Biome data serialization.: 197 MB (+ 0) -> Chunk generation.: 197 MB (+ 0) 13:30 repetitivestrain and the jit code that continues to inflate rss after these buffers are allocated, because a call to jit.flush always reduces each environment's memory requirements to the initial ~200 MB 13:30 repetitivestrain possibly as a result of the emerged area being one mapblock around the bounds of the mapchunk, even under singlenode? 13:31 sfan5 !c ((5+2)*16)**3 * 8 / (1024*1024) 13:31 MinetestBot 10.71875 13:31 sfan5 idk how much overhead a lua table has 13:32 repetitivestrain my mapchunks are 5x32x5 13:32 repetitivestrain !c (80*512*80)**3 * 8 / (1024 * 1024) 13:32 MinetestBot 268435456000000.0 13:32 repetitivestrain uh no haha 13:32 sfan5 !c (80*512*80) * 8 / (1024 * 1024) 13:32 MinetestBot 25.0 13:32 repetitivestrain !c !c (80*512*80) * 8 / 8 13:32 MinetestBot SyntaxError: invalid syntax (, line 1) 13:33 sfan5 still not 128 mb 13:33 repetitivestrain !c (80*512*80) * 8 * 3 / 8 13:33 MinetestBot 9830400.0 13:33 repetitivestrain this is literally how i instrumented the code, though: 13:34 repetitivestrain mcl_levelgen.report_consing ("-> Pre-on_generated"); local emin, emax = vmanip:get_emerged_area (); area = VoxelArea (vector.subtract (emin, minp), vector.subtract (emax, minp)); vmanip:get_data (cids); vmanip:get_param2_data (param2s); local generated = false; mcl_levelgen.report_consing ("-> on_generated") 13:34 repetitivestrain where report_consing simply runs collectgarbage ("collect") and collectgarbage ("count") before deducting the value from the result recorded during the previous call 13:54 repetitivestrain sfan5: with no mcode size limit (maxmcode=32 GB), mcode usage (as measured by the reduction in memory consumption incurred by jit.flush) plateaus at 570 MB 13:56 sfan5 per-thread? 13:56 repetitivestrain yes 13:58 repetitivestrain with the 40 mb mcode size limit that is defined in the main lua environment, the jit cache is flushed after several hundred chunks are generated, and after such a cache flush i recall that trace selection for the main terrain sampling loop would proceed much less optimally 13:58 repetitivestrain but i'm not registering the same performance impact that i did when last i benchmarked this phenomenon 14:00 repetitivestrain ye gods, i am blind 14:00 repetitivestrain https://codeberg.org/mineclonia/mineclonia/commit/0cf0b6d36c1957e8ae05b8ef915f04cf7c6fecdc 14:01 repetitivestrain i fixed the performance issue after trace flushes in august and it shouldn't be necessary to keep mcode unbounded any longer 14:08 sfan5 https://store.steampowered.com/hwsurvey/cpus/ interesting 14:09 sfan5 so most people would either get 3, 4 or 2 emerge threads 14:09 sfan5 sounds ok 14:10 repetitivestrain i concur, and thanks 15:29 erle repetitivestrain are you halon? i forgot 15:29 repetitivestrain I am, yes\ 15:30 erle repetitivestrain i understand the issues you have with faulty luajit versions. however, since you have a base function that is working and only the optimization fails, i think logging an error and using the normal unoptimized function would be enough for this use case. not every user is able to upgrade their luajit. why do you think the code being slower and a log message is not enough? 15:31 repetitivestrain erle: it's not only the optimized version that fails, but only the optimized version that is aggressively _tested_ 15:31 erle repetitivestrain also i used to do a similar tihng for faulty minetest versions, run tests at startup and complain if they failed. however, literally no one appreciated this. 15:31 erle repetitivestrain if your optimization is not tested well enough, the equivalence of it is at best questionable. 15:32 repetitivestrain the functions in question are supposed to yield mathematically well defined results, as they do on functioning versions of luajit 15:32 erle repetitivestrain are you aware of what property testing is? if so: in this case you have a property: f(x) must equal f_optimized(x). a property testing framework can make sure this is true for all x. 15:34 repetitivestrain erle: the problem is not whether the optimized and unoptimized versions are equivalent, but whether either version is compiled correctly by luajit and yields results equivalent to a completely separate ground truth 15:35 repetitivestrain there's no telling whether a defective version of luajit will operate correctly, and, on account of luajit's character as a jit and trace compiler, even when these miscompilations will manifest 15:35 erle repetitivestrain well then why don't you fall back to the base version in that case? 15:35 repetitivestrain erle: as i said, the base version is equally liable to be miscompiled 15:36 repetitivestrain the upshot is that the defective luajit cannot be tested and should be upgraded 15:36 erle repetitivestrain oh i didn't understand that. so you are saying that regardless of code path, defective luajit is unserviceable? 15:36 repetitivestrain correctly 15:36 repetitivestrain you understand correctly* 15:36 erle repetitivestrain and what is the impact of the miscompilation? 15:37 erle defective PRNG? 15:37 MTDiscord you can turn JIT off for a function, but this risks massive performance hits 15:37 repetitivestrain the rng will generate non-deterministic random values that are also inconsistent with properly functioning lua installations 15:37 repetitivestrain because luajit is a trace compiler, not even jit.off is 100% reliable 15:37 erle repetitivestrain that sounds like something that outside of cryptographic applications and test suites it should be a warning, not a crash. 15:37 repetitivestrain erle: correct 15:37 repetitivestrain erle: then the map generator will cease to be deterministic 15:39 erle repetitivestrain then mention that in the log message? i am pretty sure that most people would prefer “luajit defective, mapgen is not deterministic” as a warning over NOT BEING ABLE TO RUN THE GAME. 15:39 repetitivestrain That is worse than not being able to run the game 15:39 erle repetitivestrain unless it outputs 3 3 3 3 3 3 3 15:39 erle how? 15:39 erle i mean you have thought a lot about it, and i haven't 15:39 erle so what's the worst that could (and inevitably will) happen? 15:39 erle fucked up schematics? broken biomes? 15:39 repetitivestrain each emerge environment is completely independent of others, and the result will be that chunks generated by one emerge thread may be discontinuous with chunks generated by others, and seeds will, in difficult to observe manners, not produce the same results after a restart or on different systems 15:40 erle and this is true for all mapgens? 15:40 repetitivestrain yes 15:40 erle was it true in the past as well? 15:40 repetitivestrain on the built in map generators it'll only impact structures, but the effect is just as catastrophic 15:40 repetitivestrain no, because RNGs were not implemented in Lua in the past 15:40 repetitivestrain but there were inexplicable crashes in dripstone.lua produced by the very same luajit package 15:40 repetitivestrain dripstone's init.lua* 15:40 erle oh interesting 15:41 erle now i have a bit of experience doing bit-twiddling in lua. could you point me to the luajit issue regarding that topic so i can make sure i don't run into this? 15:43 repetitivestrain erle: search for "ARM64: Don't fuse sign extensions into logical operands" in the LuaJIT repository 15:44 repetitivestrain however, the luajit release at issue is impacted by all arm64 jit compilation issues that have been addressed since 2021 or so 15:45 repetitivestrain and should not be trusted with _any_ lua code whatever, whether it implements random number generators or merely iterates over a table 15:45 erle repetitivestrain well i do have an aarch64 laptop, does that mean i can't run it there? 15:45 erle or is aarch64 different from arm64? 15:45 repetitivestrain erle: no, it means you must _update luajit_ 15:46 repetitivestrain the OP's version of luajit was multiple years out of date and is only distributed by distributions who are wedded to tagged releases, which prevents them from accepting luajit's switch to a rolling release schedule 15:46 erle repetitivestrain do you have any idea which luajit version is the first “good” one and which one is the first “bad” one? 15:47 repetitivestrain erle: any luajit compiled from source code after 10 Sep 2023 15:47 erle repetitivestrain this seems like you *can* pinpoint which commit/release it is. 15:48 repetitivestrain but i can't disable luajit 15:48 repetitivestrain obviously 15:48 erle https://openresty.org/en/changelog-1025003.html 15:48 erle > ARM64: Fuse rotates into logical operands and don't fuse sign extensions into these operands. 15:48 repetitivestrain this is openresty's luajit distribution, yes 15:48 erle so this is the first good or first bad one? Version 1.25.3.1 - 04 Jan 2024 15:49 repetitivestrain this is an unofficial luajit fork 15:49 erle damn 15:49 repetitivestrain luajit upstream doesn't tag releases at all 15:49 MTDiscord luajit's versioning scheme is a bit weird 15:49 erle repetitivestrain great. i guess like irrlicht, at some point people will think it is dead lol 15:49 repetitivestrain users are always advised to compile luajit from the most recent revision of the repository 15:49 erle (irrlicht is not dead, it just has a very … rare … release schedule) 15:49 repetitivestrain https://luajit.org/download.html 15:50 repetitivestrain > LuaJIT uses rolling releases. There are no release tarballs available for download. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads — these links will cease to work soon. Do not use pseudo-releases or tarballs created by third parties. Do not use binaries offered for download by third parties. Pre-built packages should only be installed via a trusted 15:50 repetitivestrain package manager for your operating system (distro). But you should be aware these often carry old versions that miss important fixes. Before reporting an issue, always try the latest version available from the git repository. Distro maintainers for distros that require the fiction of a release should do frequent snapshots of a branch. Do not attempt to cherry-pick or backport individual changes, no matter how self-standing 15:50 repetitivestrain individual changes look (because they often are not). 15:50 MTDiscord are there really repos that have not caught up with luajit's rolling release scheme? 15:50 erle repetitivestrain this seems it actually fucking sucks 15:50 repetitivestrain a.corp.serot: Alpine, apparently 15:50 repetitivestrain erle: everyone else has adapted, even debian i believe 15:50 erle repetitivestrain do you have a standalone test that i can use to see if debian aarch64 code exhibits this? 15:51 repetitivestrain erle: just run "luajit random.lua" and report whether it aborts 15:51 repetitivestrain well, "luajit init.lua" 15:51 repetitivestrain in the mcl_levelgen mod directory 15:51 erle ; luajit random.lua 15:51 erle luajit: cannot open random.lua: No such file or directory 15:51 erle # exited 1 15:52 repetitivestrain it should have been apparent from context that i meant you to load this file within mineclonia's mods/MAPGEN/mcl_levelgen directory... 15:52 erle context-free or regular please 15:52 erle i have an attention deficit, furthermore i can not read minds via TCP/IP 15:53 erle i asked for a *standalone* test for a reason 15:53 erle repetitivestrain in return, i will share a standalone test so you can see if your python installation is defective. 15:53 repetitivestrain erle: i don't have any, sorry 15:53 repetitivestrain however, i think there is one in the luajit repository 15:54 repetitivestrain local t = {}; local zero = 0LL; local bit = require("bit"); for i = 1, 60 do t[i] = bit.bor(-i, zero); end; for i = 1, 60 do assert(tonumber(t[i]) == -i); end 15:55 erle repetitivestrain here is one 15:55 erle python3 -c 'import base64; print(base64.b64decode("=V=M=0="))' 15:55 repetitivestrain b'T\xcd' 15:55 erle if this does not output an error, your python3 installation is defective 15:55 repetitivestrain Oh yes haha 15:55 erle because "=V=M=0=" is not a valid base64 string 15:56 repetitivestrain Emacs passes with flying colors 15:56 repetitivestrain Debugger entered--Lisp error: (error "Invalid base64 data") base64-decode-string("=V=M=0=") 15:56 erle however, if you remove one = sign at the end, python will fail 15:56 erle (correctly) 15:56 repetitivestrain Task failed successfully 15:57 erle this error lets you infer that python3 base64 decoder is what LANGSEC people call a “shotgun parser” 15:57 erle i.e. it does not validate its inputs as the first step, and has validation logic interspersed with processing code 15:57 erle which is generally a recipe for disaster 15:58 erle for this reason, *every single time* you handle base64 data in python, you have to make sure it is really actual base64 e.g. using a regular expression (base64 is regular) 15:59 erle repetitivestrain for additional amusement, “VM0” is the beginning of the fixed point of base64 16:00 erle ; printf 'foo' |base64 |base64 |base64 |base64 |base64 |base64 |base64 |base64 16:00 erle Vm0weGQxTnRVWGxWV0dSUFZtMW9WMWxzVWxkalJuQllZMFZPVlZKVk5YVlZSbEYzVTNkdlBRbz0K 16:00 erle ; printf 'bar' |base64 |base64 |base64 |base64 |base64 |base64 |base64 |base64 16:00 erle Vm0weGQxSXlSblJXYTJSVVYwZDRXRmxyVm5kalJuQllZMFZPVlZKVk5YVlZSbEYzVTNkdlBRbz0K 16:01 erle amusing, isn't it? 16:01 repetitivestrain debian trixie's luajit is good 16:01 erle applying the encoding to itself will always produce the thing 16:01 repetitivestrain 2.1.0+openresty20250117 16:01 erle https://www.joshisanerd.com/projects/base64fixpoint/d3ish.html 16:01 erle repetitivestrain do you think the ENGINE should contain a self-test for luajit breakage? 16:02 repetitivestrain but debian oldstable's luajit is an outdated release of 2.1.0-beta3 (with backports such as luajit's developer specifically advises against) and oldoldstable's is even more hopelessly out of date 16:02 repetitivestrain erle: i think there is already some code in the CMakeFile for performing such tests, but it's far too conservative 16:03 erle repetitivestrain well it's not like the engine developers are actually known for testing things much more than the average dev, despite the former name. you are probably an outlier. 16:05 erle i used to moderate coding dojos. those are programming teamwork training games where who writes the code changes every 5 minutes or so and among the rules are “if a test fails, make it pass” and “if no test fails, implement a new test, possibly for something unimplemented”. 16:05 erle what i learned was that people who have held programmer jobs for 10 or 15 years are sometimes unwilling to write a test at all, if the result is supposed to be only like 5 lines of cdoe. 16:06 erle the tasks are stuff that is useless and of low complexity, like “add two roman numbers” 16:06 erle so that people can focus entirely on testing and team communication 16:06 repetitivestrain well we don't engage in such simulations at work, but everyone understands the advantages of aggressive testing 16:06 erle repetitivestrain well, then are you aware of property testing? 16:07 erle i happen to have held a lecture about that to a bunch of devs, was my highest-rated internal talk 16:07 repetitivestrain i am, yes, but that's not the correct form of testing here 16:07 erle repetitivestrain i understand that. i just wanted to let you know. 16:07 repetitivestrain where the object is to guarantee that each unit generates results consistent with a precomputed ground truth 16:07 erle well, in that case, you have your property 16:07 erle it just needs to be precomputed 16:08 erle “function output matches oracle” is a very common thing that people rarely test 16:08 erle but it *is* a property 16:08 erle like, one of the seven (or eight?) basic properties i told people about 16:08 repetitivestrain the property in question is purely fortuitously implemented by Microsoft in Java, but that's as maybe 16:08 erle “purely fortuitously”, what does tat mean? 16:09 repetitivestrain uh it means it is a circumstance that arose by chance rather than for a purpose 16:09 repetitivestrain accidentally 16:09 repetitivestrain coincidentally 16:10 repetitivestrain and it is proprietary, yes, so i can't incorporate it into mineclonia or even acknowledge its presence, and my knowledge of it was derived not from reading its source code, but public documentation elsewhere, and writing batteries of unit tests linked against unmodified minecraft class files, with the assistance of yarn mappings 16:10 repetitivestrain acknowledge its existence* 16:11 erle repetitivestrain oh right i get it 16:12 erle repetitivestrain the “exactly like minecraft” thing 16:12 erle hard to test a PRNG without a cross-language property testing framework (and even then) 16:13 repetitivestrain for example: microsoft's version of java's default prng does not match the implementation in openjdk and the java specification 16:13 erle repetitivestrain thanks i hate it 16:13 repetitivestrain https://bugs.mojang.com/browse/MC/issues/MC-239059 16:13 erle repetitivestrain so that means if you run M***C***** using openjdk or so it fails? 16:14 erle i used to browse the mojang bug tracker for funsies when i needed a laugh 16:14 erle it's *very* funny at times 16:14 cheapie repetitivestrain: Is this supposed to load eventually? 16:14 erle best thing i found was an autocloser bot that responded to “i can confirm that this issue is NOT a duplicate of #whatever” with “closed as duplicate of issue #whatever” 16:14 repetitivestrain no, but now imagine how many weeks i had a slightly defective prng, derived from the openjdk implementation, before inconsistencies with minecraft in the seeding of certain noises on very specific seeds led me independently to diagnose their bug and locate this issue ^ 16:14 repetitivestrain cheapie: is what? 16:15 erle repetitivestrain reverse engineering is a pain 16:15 cheapie repetitivestrain: The page you linked, it just shows a loading spinner and nothing else 16:15 erle cheapie might be js or adblocker shenanigans 16:15 repetitivestrain oh, it's microsoft's fault then 16:15 cheapie I don't have JS blocked and my ad blocker reports not having blocked anything on this page, *shrug* 16:16 sfan5 doesn't load for me in either firefox or chromium 16:16 repetitivestrain Hahaha 16:16 erle well, mojang delivers again 16:16 repetitivestrain leave it to Microsoft not to be able to keep an issue tracker online 16:16 erle fun for the whole internet 16:17 erle repetitivestrain ever since they overtook github it became SLOW in some browsers. i believe safari? 16:17 erle what a coincidence. right up the alley with youtube being slower in firefox 16:17 repetitivestrain i don't use github anyway 16:17 repetitivestrain well, i browse it, but only with noscript on 16:18 erle yeah me too, it became worse and worse 16:18 erle i mean forgejo is kinda shitty performance-wise lately 16:18 erle but github takes the cake 16:18 repetitivestrain cheapie: anyway, the issue was that the final rshift for truncating the lcg state when the desired number of bits is fewer than 48 was arithmetic in mojang's implementation 16:19 repetitivestrain while openjdk's was a logical operation 19:45 crazylad man, #16239 should get merged lol 19:45 ShadowBot https://github.com/luanti-org/luanti/issues/16239 -- Add new setting to enable/disable dark mode in main menu by ZenonSeth 19:46 crazylad I even forked this PR to be able to set the top half and bottom half of the menu sky by passing a second parameter to 'core.set_sky_color()'