I recently bought a Netgear WNDR4300 router. Normally my computer accesses the Internet through the router’s NAT, but sometimes I need a direct connection to the campus network—for example, when I need to expose a port and cannot figure out the port-forwarding interface. Unplugging the cable from the router every time is too much trouble.

Although Windows lets you change its language by installing a language pack, in typical Microsoft fashion, some ancient leftovers do not follow that setting. Language packs, which apparently disturb the purity and harmony of the system, are no exception:

Another year somehow passed while I was idling away, and this novice has made no progress—if anything, I have become worse. My GPA hit a new low this semester, and I could already picture myself becoming a Yuquan-campus shut-in next term. Fortunately, today this shut-in finally finished configuring a personal mail server. My new address is wu@x-nagi.com; feel free to send me mail.

I recently needed OpenSSL on Windows for a challenge. I had always built it through MSYS/MinGW, which produces the static libraries libcrypto.a and libssl.a (as well as DLLs, although I generally prefer static linking). Programs compiled with GCC can use them with -lssl -lcrypto. These libraries only work with MinGW, however, and cannot be used by Visual Studio; MinGW’s Win32 API support is hardly praiseworthy either. I therefore investigated how to build OpenSSL with Visual C++.

The final TLS 1.3 specification, RFC 8446, was published in August 2018. Out of curiosity, I installed OpenSSL 1.1.1 to enable TLS 1.3 support. Recently, however, I noticed that Nginx always selected TLS_AES_256_GCM_SHA384 under TLS 1.3, regardless of the cipher-suite order in ssl_ciphers; even explicitly requesting AES-128 made no difference. This was not a serious problem, but to a would-be perfectionist it made the configuration feel incomplete.