Below code should output 00000000fc52127e31b9685a7fc3bdda302494879630be65bffa2dc38b680ac9 with -O2; clang-20, clang-21, clang-22 produce different output on x64 (see Issue 215690).

// x.cpp
#include <cstdint>
#include <cstdio>
#include <cstdlib>

__attribute__((noinline)) void bar(uint8_t *b, size_t size)
{
        const uint32_t k = 0xc93e5407;
        for (uint32_t i = 0; i < size; i++)
        {
                b[i] ^= ((uint8_t*)&k)[i % sizeof(uint32_t)];
        }
}

int main() {
        uint8_t y[] = "\x07\x54\x3e\xc9\xfb\x06\x2c\xb7\x36\xed\x56\x93\x78\x97\x83\x13\x37\x70\xaa\x4e\x91\x64\x80\xac\xb8\xae\x13\x0a\x8c\x3c\x34";
        const size_t n = sizeof(y);
        bar(y, n);
        for (size_t i = 0; i < n; i++) printf("%02x", y[i]); puts("");
}

Just compile with clang++-22 -O2 x.cpp on x64; clang 19.1.7 (20ubuntu4) is OK, clang 22.1.2 (1ubuntu1) is NG.

-opt-bisect-limit indicates that loop-vectorize breaks things (see Using -opt-bisect-limit): compile with clang++-22 -O2 -mllvm -opt-bisect-limit=87 -c x.cpp to see/bisect which optimization step breaks the output.

The __attribute__((noinline)) is helpful to actually reproduce the issue in a single file; otherwise different compilation units do the thing.

posted at: 01:03 | path: /programming | permanent link

Struggled to get Cascadia and Expedition 33 running on Steam under Linux.

I noticed the following output when running (a very recent) wine:

GL_INVALID_ENUM in glTexBufferRange(internalFormat GL_RGBA8_SNORM

and the fact that the OpenGL renderer was used and it might not implement certain texture formats (I'm using a AMD Ryzen 5600G with its internal GPU).

After installing mesa-vulkan-drivers (which was apparently missing for whatever reason), things switch to the Vulkan renderer and started working. Hurray!

fo:  Game: SandFall-Win64-Shipping.exe
info:  DXVK: v3.0.2
info:  Build: x86_64 gcc 16.1.0
info:  Vulkan: Found vkGetInstanceProcAddr in winevulkan.dll @ 0x6ffff9007840
...
info:  Found device: AMD Radeon Graphics (RADV RENOIR) (radv 26.1.5)
info:  Found device: llvmpipe (LLVM 21.1.8, 256 bits) (llvmpipe 26.1.5)

posted at: 23:46 | path: /configuration | permanent link

So far I have just ignore bots visiting my resources, no more. There is just no limit, in particular for rather expensive script-generated content. So...

RewriteCond %{HTTP_USER_AGENT}  ^.*(GPTBot|Amazonbot|ClaudeBot|bingbot|meta-externalagent|PetalBot|DotBot|GoogleBot|SemrushBot|Sogou|AhrefsBot|YandexBot|applebot).*$ [NC]
RewriteRule .* - [R=410,L]

posted at: 22:34 | path: /rant | permanent link

Try systemd-analyze blame to find out which service takes long during bootup.

For me, it was systemd-networkd-wait-online.service, apparently timing out after 2 minutes. Probably it tries to bring up all network interfaces (my PC has two NICs).

So: try SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout 5 --any to see if it can quickly bring up at least one interface within 5 seconds.

Edit /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service and add the paramters above (-timeout 5 --any) to line ExecStart=/usr/lib/systemd/systemd-networkd-wait-online.

posted at: 00:42 | path: /configuration | permanent link

Postfix, when configured with multiple domains, should present a different certificate upon STARTTLS depending on the domain (via SNI).

In /etc/postfix/main.cf, there is tls_server_sni_maps which points to a hash file, e.g. hash:/etc/postfix/vmail_ssl.map with the following content (assuming Let's Encrypt certificates):

mail.domain1.com /etc/letsencrypt/live/mail.domain1.com/privkey.pem /etc/letsencrypt/live/mail.domain1.com/fullchain.pem
mail.domain2.net /etc/letsencrypt/live/mail.domain2.net/privkey.pem /etc/letsencrypt/live/mail.domain2.net/fullchain.pem

The postmap -F hash:/etc/postfix/vmail_ssl.map command has to be run on update of the certificates.

Run ssltestssl --starttls smtp mail.domain2.net:25 to checkk the setup.

posted at: 21:36 | path: /configuration | permanent link