Fighting with computers

As I mentioned in my previous entry, I migrated a library from Java to C++ to make it easier to use from Python. I tested its performance on both Linux and OSX, and it was on par with the Java version. Sample file S266.txt would take around 45 seconds on my computer using the Java version, and the C++ version needed thirty-something seconds on a M1 MacBook Pro running OSX, a bit less than that on an i9-13900 server running Linux. From that, I could not claim there was a huge difference in performance compared to the original Java runtime. But I wanted to make a fair comparison, and I wanted to face the trouble of building the library for Windows. It was not a challenge, but it took a while. Let me summarize all the steps I needed to cover: Install Microsoft's Visual Studio (Community Edition) Install Microsoft's vcpkg (C++ package manager) Install CMake. Install dependencies (tbb, gtest, boost, pybind11) Clone the project repository . Build the project. It took me like an hour...

Today, we embarked on an ambitious software engineering journey: migrating a sophisticated 2D bin packing program from its original Java implementation into a high-performance C++ library, complete with Python bindings for ease of use. The goal was to retain 100% of the original complex packing logic while unlocking the raw speed of C++. The heart of this migration involved replacing Java's powerful java.awt.geom.Area class. We chose the world-class Boost.Geometry library as its C++ counterpart, meticulously re-implementing every geometric operation, from simple transformations to complex polygon intersections and subtractions. This formed the foundation upon which we rebuilt the original program's advanced packing heuristics. We successfully ported a multi-stage packing strategy, including bounding-box placement, a "drop" simulation for gravity-fed placement, and iterative compression algorithms. However, real-world testing with complex, high-vertex-count polygons r...

Today, I set out to configure a remote access VPN for my small office. My first choice was L2TP/IPsec with StrongSwan and xl2tpd , mainly because it’s supported natively by Windows. It seemed like a solid option; secure and well-documented. But several hours later, after wading through IKE version mismatches, arcane config options, and ambiguous Windows error codes, I hit a wall. Despite correctly setting up IPsec and L2TP, Windows insisted on trying IKEv2, and StrongSwan repeatedly rejected the connections. Exhausted by endless logs and incompatible defaults, I decided to abandon the legacy stack and try something different: OpenVPN . In under ten minutes, using the widely respected OpenVPN install script by Angristan , I had a working VPN server. The script handled everything—certificates, firewall rules, user config—and generated a ready-to-go .ovpn file. I dropped it into OpenVPN Connect on Windows , hit "Connect", and just like that, it worked . Sometimes the best t...