not-matthias

Why glibc is faster on GitHub Actions

2026-03-03T00:00:00+00:00

Originally published on the CodSpeed blog</a>.

Pre-commit deleted all unstaged files

2025-11-22T00:00:00+00:00

I was working on a new feature at $JOB and wanted to commit my changes from the last hour. I staged a few files, entered the commit message, committed them and waited for the pre-commit hooks to pass.

Unfortunately, the pre-commit hooks didn't pass because I had some style issues. And since I was using VSCode, I closed the dialog thinking that I just have to run cargo fmt</code> once more. Then I realized that all my non-staged files were deleted.

How to restore those files?</h1>
Attempt 1: Git Stash/Reflog</strong> - I didn't exactly know what pre-commit</code> was doing, so I thought that maybe they are just stashing the unstaged files like you can do with the git stash --keep-index</code> command. Unfortunately, I didn't find any new stash entries. Becoming a bit nervous, I also wanted to double check if there was a reflog entry for the deleted files. However, I couldn't find any reflog entries either.</p>

Attempt 2: VSCode File History - There's a really useful command in VSCode called Local History: Find Entry to Restore</code> which keeps track of all the file changes. This would have allowed me to restore all my files, but I was using Zed</a> at the time which doesn't have this feature.

Attempt 3: Claude Session: I was using Claude to spec parts of the feature and do simple refactorings, so I was hoping it still had some of the file content in the conversation history. This approach worked, but it was mostly outdated and didn't contain all my lost files. Since I didn't want to rely on the CLI, I went into the ~/.claude</code> directory to search for parts of the content. There I discovered that its also storing a backup of each file in the ~/.claude/file-history</code> folder which you can search through. Unfortunately, this also only contained outdated content.

Attempt 4: Pre-commit Cache: After I finished restoring parts of my content with Claude, I wanted to commit the changes ASAP to not lose them again. This time, I was using the git</code> CLI which failed again, losing all my changes...again. Luckily, this time I had the full logs of what went wrong.

$</span> git</span> commit</span> -</span>-amend</span> -</span>-no-edit</span></span>
[</span>WARNING</span>]</span> Unstaged files detected.</span></span>
[</span>INFO</span>]</span> Stashing unstaged files to /home/not-matthias/.cache/pre-commit/patch1763743901-1677171.</span></span>
trim</span> trailing</span> whitespace.................................................Passed</span></span>
fix</span> end</span> of</span> files.........................................................Passed</span></span>
check</span> yaml...........................................</span>(</span>no</span> files</span> to</span> check</span>)</span>Skipped</span></span>
check</span> toml...............................................................Passed</span></span>
check</span> for</span> added</span> large</span> files..............................................Passed</span></span>
fmt..................................................(no</span> files</span> to</span> check</span>)Skipped</span></span>
cargo</span> check..........................................</span>(</span>no</span> files</span> to</span> check</span>)</span>Skipped</span></span>
clippy...............................................(no</span> files</span> to</span> check</span>)Skipped</span></span>
[</span>WARNING</span>]</span> Stashed changes conflicted with hook auto-fixes... Rolling back fixes...</span></span>
An</span> unexpected</span> error</span> has</span> occurred:</span> CalledProcessError:</span> command:</span> (</span>'</span>/nix/store/639k78iljhfmciklnivi0wja8jcy788g-git-2.50.1/libexec/git-core/git</span>'</span>,</span> '</span>-c</span>'</span>,</span> '</span>core.autocrlf=false</span>'</span>,</span> '</span>apply</span>'</span>,</span> '</span>--whitespace=nowarn</span>'</span>,</span> '</span>/home/not-matthias/.cache/pre-commit/patch1763743901-1677171</span>'</span>)</span></span>
return</span> code:</span> 1</span></span>
stdout:</span> (none</span>)</span></span>
stderr:</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__perf_map__tests__ld_linux_symbols.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__perf_map__tests__ld_linux_symbols.snap:</span> patch</span> does</span> not</span> apply</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__cpp_unwind_data.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__cpp_unwind_data.snap:</span> patch</span> does</span> not</span> apply</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__golang_unwind_data.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__golang_unwind_data.snap:</span> patch</span> does</span> not</span> apply</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__ruff_unwind_data.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__ruff_unwind_data.snap:</span> patch</span> does</span> not</span> apply</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__rust_divan_unwind_data.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__rust_divan_unwind_data.snap:</span> patch</span> does</span> not</span> apply</span></span>
    error:</span> patch</span> failed:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__the_algorithms_unwind_data.snap:1</span></span>
    error:</span> src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__the_algorithms_unwind_data.snap:</span> patch</span> does</span> not</span> apply</span></span>
Check</span> the</span> log</span> at</span> /home/not-matthias/.cache/pre-commit/pre-commit.log</span></span></code></pre>
The most important line is this, which pointed me to the cache of pre-commit:</p>
[INFO] Stashing unstaged files to /home/not-matthias/.cache/pre-commit/patch1763743901-1677171.</span></span></code></pre>
Looking at the file, I could see that this is just a git diff that was written to a file. We can restore it easily with the patch</code> command:</p>
$</span> patch</span> -</span>p1</span> <</span> /home/not-matthias/.cache/pre-commit/patch1763742759-1588111</span></span>
patching</span> file</span> crates/heaptrack/Cargo.toml</span></span>
patching</span> file</span> crates/heaptrack/src/bpf.rs</span></span>
patching</span> file</span> crates/heaptrack/src/events.rs</span></span>
patching</span> file</span> crates/heaptrack/src/main.rs</span></span>
.</span>.</span>.</span></span>
patching</span> file</span> crates/runner-shared/src/lib.rs</span></span>
patching</span> file</span> flake.nix</span></span></code></pre>Why did I fail?</h1>
I also managed to find the root cause of the pre-commit</code> failure. For some reason, some test snapshots which should be stored in Git LFS weren't stored correctly. This even makes git stash</code> fail:</p>
$</span> git</span> stash</span></span>
Saved</span> working</span> directory</span> and</span> index</span> state</span> WIP</span> on</span> cod-1670-runner-profile-memory-of-command:</span> bb882e9</span> fixup:</span> runner-shared</span></span>
Encountered</span> 6</span> files</span> that</span> should</span> have</span> been</span> pointers,</span> but</span> weren</span>'</span>t:</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__perf_map__tests__ld_linux_symbols.snap</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__cpp_unwind_data.snap</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__golang_unwind_data.snap</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__ruff_unwind_data.snap</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__rust_divan_unwind_data.snap</span></span>
        src/run/runner/wall_time/perf/snapshots/codspeed__run__runner__wall_time__perf__unwind_data__tests__the_algorithms_unwind_data.snap</span></span></code></pre>
To fix it, I had to run git lfs migrate import --fixup</code> which resolved the issue. Then the pre-commit</code> hook worked correctly again as well.</p>
Conclusion</h1>
I just wanted to write about this in case anyone else encounters the same issue. There are quite a few tricks to recover lost files nowadays, because many tools are copying them and storing them somewhere</em>. For example, a colleague at work lost his ZSH history, but managed to recover it since he was using Amazon Q</a> which sent his history to the cloud, but also kept a local copy.</p>
So I guess it's time to thanks all the companies that collect and sell our data, as long as they store it locally so that we can use it for backups.</p>

Black-Box Binary Analysis using API-Only Tracing 2025-07-01T00:00:00+00:00 Tracking Anticheat Updates 2025-06-26T00:00:00+00:00 A few years ago when I was into reverse engineering and binary analysis (and game modding), I did a lot of research into anticheats work. I was curious about tracking their updates, since that would allow me to: Know when a new version is released</li> Understand what changes were made</li> Use older versions for research purposes</li> </ul> So I ended up researching different ways on how to track updates of various anticheats. Some of them are already very well documented, while others haven't been explored much. This post will summarize my findings and outline how they work. EasyAntiCheat</h1> EasyAntiCheat is widely recognized as one of the most advanced anticheats, and is used in many popular games like Rust, Fortnite, Apex Legends, and more. Prior to the acquisition by Epic Games, EAC was using their own CDN to distribute updates: https://download.eac-cdn.com/api/v1/games/{game_id}/client/{system}/download/?uuid=1239688</code>. game_id</code>: unique identifier for each game (e.g. 154 for Apex Legends)</li> system</code>: target platform/system (e.g. wow64_win64</code>, mac64</code>, linux32_64</code>).</li> </ul> After the acquisition, they switched to the EpicGames CDN, which has a slightly different URL structure: https://modules-cdn.eac-prod.on.epicgames.com/modules/{product_id}/{deployment_id}/{system}</code>. The parameters to this URL are completely different: product_id</code>: unique identifier for each game (e.g. 429c2212ad284866aee071454c2125b5</code> for Rust)</li> deployment_id</code>: unique identifier for each deployment (e.g. 76796531e86443548754600511f42e9e</code> for Rust). This doesn't change when an update is released and is used to identify different game versions.</li> system</code>: same as in the old CDN</li> </ul> After downloading the module for a game, we'll have a file which contains data with a very high entropy which is the first indication that it is encrypted or compressed: $ bat encrypted.bin | ent Entropy = 7.989390 bits per byte.</code></pre> Looking at the data, we also can't really identify any patterns or strings. However, across versions the header seems to always stay the same (a7 ed</code>): Very interesting 🤔 $ hexyl encrypted.bin | head ┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐ │00000000│ a7 ed 96 0c 0f 0f 12 19 ┊ 1c 1b 1e 20 22 26 2a e5 │×××_••••┊••• "&*×│ │00000010│ e8 33 36 39 3c 3f 42 85 ┊ 88 4b 4e 51 54 57 5a 5d │×369<?B×┊×KNQTWZ]│ │00000020│ 60 63 66 69 6c 6f 72 75 ┊ 78 7b 7e 81 84 87 8a 8d │`cfiloru┊x{~×××××│ │00000030│ 90 93 96 99 9c 9f a2 a5 ┊ a8 ab ae 31 34 b7 ba cb │××××××××┊×××14×××│ │00000040│ ed 9c 8e d7 80 8c a8 c3 ┊ b1 94 2b fa d2 5c a6 be │××××××××┊××+××\××│ │00000050│ cc 86 86 db dd d5 db d8 ┊ d6 98 91 d5 e3 f3 f7 00 │××××××××┊×××××××⋄│ │00000060│ b4 a5 ed ae be 16 15 c3 ┊ c1 12 cc a5 d7 e9 bd da │×××××••×┊×•××××××│ │00000070│ 2c 26 1f ec 97 79 79 93 ┊ 8c 6b 6e 71 74 77 7a cd │,&•××yy×┊×knqtwz×│ │00000080│ 15 c8 86 d5 d9 93 95 c9 ┊ 4d 6e 58 09 a4 a7 aa ad │•×××××××┊MnX_××××│</code></pre> A few years ago, I spent a night</del> early morning with a friend to find the decryption algorithm. We searched for anything that closely resembled such an algorithm, eventually found it, made a quick POC and got it working 🔥. Here's what the code looks like: void decode(char *memory_block, int total_size) { char* buffer = (char*)memory_block; int file_size = total_size; if (file_size >= 2) { buffer[file_size - 1] += 3 - 3 * file_size; int current_index = file_size - 2; if (file_size != 2) { do { buffer[current_index] += -3 * current_index - buffer[current_index + 1]; --current_index; } while (current_index); } buffer[0] -= buffer[1]; } }</code></pre> After decrypting the binary blob, we'll finally have a PE image (EasyAnticheat.packed.dll</code>): $ hexyl EasyAnticheat.packed.dll | head ┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐ │00000000│ 4d 5a 90 00 03 00 00 00 ┊ 04 00 00 00 ff ff 00 00 │MZ×.•...┊•...××..│ │00000010│ b8 00 00 00 00 00 00 00 ┊ 40 00 00 00 00 00 00 00 │×.......┊@.......│ │00000020│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │........┊........│ │00000030│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 80 00 00 00 │........┊....×...│ │00000040│ 0e 1f ba 0e 00 b4 09 cd ┊ 21 b8 01 4c cd 21 54 68 │••×•.×_×┊!×•L×!Th│ │00000050│ 69 73 20 70 72 6f 67 72 ┊ 61 6d 20 63 61 6e 6e 6f │is progr┊am canno│ │00000060│ 74 20 62 65 20 72 75 6e ┊ 20 69 6e 20 44 4f 53 20 │t be run┊ in DOS │ │00000070│ 6d 6f 64 65 2e 0d 0d 0a ┊ 24 00 00 00 00 00 00 00 │mode.___┊$.......│ │00000080│ 50 45 00 00 4c 01 03 00 ┊ 34 81 52 68 00 00 00 00 │PE..L••.┊4×Rh....│</code></pre> Unfortunately, we're not yet done. According to Detect it Easy</a>, the binary is protected with VMProtect, which means we can't just read the .text</code> or .data</code> section. However, to further analyze the binary and extract the driver and usermode module we'll have to find a way to unpack it. There are many ways to unpack binaries, with the most popular being emulation and native execution. Both methods just execute the entrypoint until the sections are unpacked. In our case, the easiest way to unpack the downloaded binary is to load it with LoadLibraryA</code>: use windows::{ core::PCSTR, Win32::{Foundation::HINSTANCE, System::LibraryLoader::LoadLibraryA}, }; use pelite::pe32::PeView; use std::path::PathBuf; fn main() { let file = PCSTR::from_raw("temp.dll\0".as_ptr() as _); let Ok(module) = unsafe { LoadLibraryA(file) } else { eprintln!("Failed to load library: {}", error); return; }; println!("Loaded module: {:x?}", module); let pe = unsafe { pelite::PeView::module(module.0 as *const u8) }; /* Analyze the unpacked module */ }</code></pre> After analyzing this unpacked library, you'll eventually figure out that the .data</code> section has a high entropy and is quite large. You might even recognize the encrypted PE headers from earlier: a7 ed</code>. This is exactly where the driver and their internal module are stored. The embedded files use the same encryption algorithm, so we can search for the encrypted PE header (MZ</code> or 0x4D5A</code>). After looking at the data in IDA, I managed to find a pattern which we can use to extract the embedded files. The encrypted modules are always stored in the following order: <encrypted_module> (encrypted data) <size> (padded to 16 bytes)</code></pre> This is somewhat equivalent to the following structure, where len always contains the size of the buffer: struct EncryptedModule { buffer: [u8], len: u64, padding: u64 // always 0 }</code></pre> By knowing that the encrypted module has a high entropy, which means that it's very unlikely that there will be patterns in the data, we can simply search for at least 8 bytes of zero padding which is always present after the size. let section = pe.section_by_name(".data"); let (driver_start, driver_end) = section.find_padding_at(0); let encrypted_driver = section[driver_start..driver_end]; let driver_module = decode(encrypted_driver); assert_eq!(driver_module[..2], &[0x4D, 0x5A]); let (internal_start, internal_end) = section.find_padding_at(driver_end); let encrypted_internal = section[internal_start..internal_end]; let internal_module = decode(encrypted_internal); assert_eq!(internal_module[..2], &[0x4D, 0x5A]);</code></pre>Battleye</h1> Battleye, another popular anticheat from Germany, is known for its bandaid fixes and lack of security</a>. They put a lot of focus on detecting popular cheat providers, by detecting them via static signatures. It is used in games like Arma, DayZ, Escape from Tarkov, and most recently Grand Theft Auto V. Their CDN seems to be built in-house and follows a very simple structure: Fetch the latest version (which is just a unix timestamp like 1746714230</code>)</li> Download the module using the version number from the actual CDN</li> </ol> Here are the required URLs: Version URL: https://cdn.battleye.com/{game}/ver</code></li> Download URL: https://cdn.battleye.com/{game}/{version}</code></li> Possible values for the games include: eft</code>, unturned</code>, ark</code>, r6s/win-x64</code>, dayz/win-x64</code>.</li> </ul> The downloaded binary contains other bytes before the actual module, which have to be filtered out. The easiest way to do it is to search for the PE header and delete everything before. In this case, the PE module is located at offset 0x200: $ binwalk 1732793154 --------------------------------------------------------------------------------- DECIMAL HEXADECIMAL DESCRIPTION --------------------------------------------------------------------------------- 512 0x200 Windows PE binary, machine type: Intel x86-64 ---------------------------------------------------------------------------------</code></pre> The downloaded file is BEService.exe</code>, which also embeds their kernel driver which is extracted when the service is started. You can use similar techniques as with EAC to extract it, so I won't go into further details. While writing this blog post, I realized that some old download URLs of mine still worked. So it seems like the CDN is keeping not only the latest but also previous builds. Since the epoch timestamp only counts the seconds since 1970, it should only take a few days to enumerate all possible IDs. I've thrown together a quick POC, and unfortunately it seems like they are deleted old version :( Electronic Arts Anti-Cheat (EA-AC)</h1> EA-AC</a> (not to confuse with EAC) is a relatively new anticheat that was launched in 2022. It is used in games like FIFA or Battlefield, which all use the same installer. The direct download link to their installer can be found on the help.ea.com</a> page which links to the following URL: https://cdn.eaanticheat.ac.ea.com/EAAntiCheat.Installer.exe</code>. Instead of having to run the installer, we can simply usage 7z</code> to extract the contents. However, they are not shipping the driver with the installer anymore, so you need to dump it while running the game or reverse engineer the download. $ 7z l EAAntiCheat.Installer.exe Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ 2025-06-14 08:03:50 ..... 44388600 26865015 ProgramFiles/EAAntiCheat.GameService.dll 2025-06-14 08:03:36 ..... 116300024 108845059 ProgramFiles/EAAntiCheat.GameService.exe 2025-06-14 08:04:12 ..... 26872 14232 ProgramFiles/preloader_s.dll 2025-06-14 08:03:50 ..... 37148408 20349480 Title/EAAntiCheat.GameServiceLauncher.dll 2025-06-14 08:03:50 ..... 15922936 13955947 Title/EAAntiCheat.GameServiceLauncher.exe 2025-06-14 08:04:12 ..... 27384 14245 Title/preloader_l.dll ------------------- ----- ------------ ------------ ------------------------ 2025-06-14 08:04:12 213814224 170043978 6 files</code></pre>Vanguard</h1> Vanguard</a> is the anticheat used in Valorant and League of Legends, developed by Riot Games. Despite their advanced security features, is is relatively easy to track the updates. They provide a public API to fetch the latest config which includes the version and URL for the anticheats modules: https://clientconfig.rpg.riotgames.com/api/v1/config/public</code> { "anticheat.vanguard.backgroundInstall": false, "anticheat.vanguard.enabled": true, "anticheat.vanguard.enforceExactVersionMatching": false, "anticheat.vanguard.steppingStones": [ "1.16.15.9" ], "anticheat.vanguard.url": "https://riot-client.secure.dyn.riotcdn.net/channels/public/rccontent/vanguard/{version}/setup.exe", "anticheat.vanguard.version": "1.17.6.2", ... }</code></pre> After downloading the files from the CDN and extracting them (again either via 7z</code> or by running the installer), we'll have the following files. This already includes the driver and usermode components, so we don't even have to extract anything. $ 7z l setup.exe Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ 2025-05-05 20:43:53 ....A 21651 6298 vgc.ico 2025-05-05 20:54:45 ....A 4494048 55866276 installer.exe 2025-05-05 20:57:34 ....A 4285400 log-uploader.exe 2025-05-05 20:55:20 ....A 40075376 vgc.exe 2025-05-05 14:18:24 ..... 26955888 vgk.sys 2025-05-05 20:55:53 ....A 10524776 vgm.exe 2025-05-05 20:56:48 ....A 3239456 vgrl.dll 2025-05-05 20:57:10 ....A 4143376 vgtray.exe ------------------- ----- ------------ ------------ ------------------------ 2025-05-05 20:57:34 93739971 55872574 8 files</code></pre>Conclusion</h1> It's surprising to see the differences in CDNs for different anticheats. You might think, why don't all anticheats have a state-of-the-art military-grade quantum-proof AI encrypted CDN™: Turns out it doesn't matter if people can extract all of the anticheat modules or figure out when the anticheat updates. At best, it makes it a little bit more inconvenient or time consuming for researchers (which is pretty much the whole purpose of an anticheat). The main purpose is to protect the games and this is done by protecting the modules that do the detections rather than the CDN. I worked on this project a few years ago, even gave a talk at a local meetup about the architecture, but never got around to publish a blog post about the internals. I really enjoyed working on this project, trying out new tech stack and learning about devops, deployment, object storage (MinIO) and a lot more. While some of the information likely is not unknown anymore, I still hope you learned something. Appendix</h1> EQU8</h2> EDIT: Turns out the CDN doesn't work anymore, but I wanted to include it for the sake of completeness EQU8 is an anticheat developed primarily for the game Splitgate. It isn't as advanced as the previously mentioned anticheats, but still provides some level of protection against cheaters. The download URL is as follows: https://download2.equ8.com/v1/a1/{id}/updates.json</code>, where {id}</code> is a unique identifier for the game (e.g. 36 for Splitgate) This response can be parsed with the following structures: #[allow(unused)] #[derive(Debug, Deserialize)] struct Component { pub name: String, pub server_path: String, pub install_path: String, pub rule: String, pub size: i64, pub hash: String, } #[derive(Debug, Deserialize)] struct UpdateComponents { pub components: Vec<Component>, } #[derive(Debug, Deserialize)] struct GameUpdate { pub update: UpdateComponents, }</code></pre> We can then search for the anticheat.x64.equ8.exe</code> file which is the main executable and download it. FACEIT</h2> FACEIT is the anticheat of private leagues for games such as CSGO or League of Legends. They are one of the top anticheats in this space due to their invasive checks and little public information about their detections. You can find the download link on their anticheat page</a> which links to here: https://anticheat-client.faceit-cdn.net/FACEITInstaller_64.exe It only includes the frontend iirc, and I didn't spend much more time on it. ESEA</h2> This anticheat requires you to have an account, and last time I checked their download page had a CAPTCHA, making it a little bit more inconvenient to track updates. Anyways, here's the download link: https://play.esea.net/index.php?s=downloads&d=download&id=1 Now 2025-06-04T00:00:00+00:00 What am I up to right now? Working at Codspeed</a> as a systems engineer.</li> Learning Chinese on Duolingo</li> </ul> What is this? This is a Now page</a> to share what I'm currently doing. Redesigning my blog 2025-06-04T00:00:00+00:00 My blog was overdue for a change. It's been more than 3 years since I created the theme for this blog and I've grown to dislike some things about it. So I decided to use my extended weekend to redesign it. This post will act as a showcase of the changes I made and some thoughts on the design choices. New Fonts!</h1> I want to ask the the version of me from 3 years ago: Why the hell did you use a monospace font for the text? I really don't know. I guess I spent so much time coding, that I wanted to have the same kind of look on my blog as well. However, when looking at old blog posts, I feel like it makes it much harder to read and follow. And no popular website or tech blogger uses them as a main font, so there's probably a reason for that. But choosing good fonts is hard, especially when you want to match it with the design of your site. My current solution for this is browsing blogs of other people and checking what fonts they use. </div> New /talks page</h1> The projects page was added at a later point, and I am still happy with what I came up with. When I decided to also add a talks page, I reused the same design and implementation, but it doesn't fit that well. Talks have a description, date, location, slides and video link, which makes it quite different from the projects. Additionally, having two cards per row makes it look cramped and confusing (see left).

not-matthias

Why glibc is faster on GitHub Actions

Pre-commit deleted all unstaged files

Why did I fail?</h1> I also managed to find the root cause of the pre-commit</code> failure. For some reason, some test snapshots which should be stored in Git LFS weren't stored correctly. This even makes git stash</code> fail:</p>

Black-Box Binary Analysis using API-Only Tracing

Tracking Anticheat Updates

Appendix</h1>

ESEA</h2> This anticheat requires you to have an account, and last time I checked their download page had a CAPTCHA, making it a little bit more inconvenient to track updates. Anyways, here's the download link: https://play.esea.net/index.php?s=downloads&d=download&id=1</p>

Now

Redesigning my blog

ESEA</h2>
This anticheat requires you to have an account, and last time I checked their download page had a CAPTCHA, making it a little bit more inconvenient to track updates. Anyways, here's the download link: https://play.esea.net/index.php?s=downloads&d=download&id=1</p>