https://coder.tw/en/Recent content on Lin's BlogHugoen-USTue, 20 Oct 2026 07:59:50 +0800https://coder.tw/en/posts/ios-remote-deploy-over-wireguard/Tue, 20 Oct 2026 07:59:50 +0800https://coder.tw/en/posts/ios-remote-deploy-over-wireguard/<p>In the age of AI, many of us control our home computers remotely and let AI write code while we are out. Web development is easy: connect the computer to Tailscale or WireGuard, and you can open the page and debug from anywhere. Apps are different. App Store review takes days, and even TestFlight takes about half an hour before you can install a build on your phone. No matter how fast AI writes code, you get stuck here.</p>https://coder.tw/en/posts/openrouter-ai-model-provider-differences/Mon, 19 Oct 2026 22:20:15 +0800https://coder.tw/en/posts/openrouter-ai-model-provider-differences/<p>I recently used DeepSeek V4.1 Flash on OpenRouter and ran into a frustrating problem: the same model was sometimes smart and sometimes clearly dumb. When it was dumb, it even got the tool call format wrong, or kept repeating the same step without making progress. The model name never changed, yet it felt like a different model. This made me notice something that is easy to overlook: <strong>besides choosing a model, which provider actually runs the model also affects the experience.</strong></p>https://coder.tw/en/posts/opensearch-memory-alert-old-generation/Mon, 19 Oct 2026 22:19:33 +0800https://coder.tw/en/posts/opensearch-memory-alert-old-generation/<p>I manage close to a hundred OpenSearch clusters. A while ago, the heap alert started firing, but only on a few clusters, not all of them. The alert fires when heap usage goes above 75%. On those few clusters, it would recover by itself a few minutes later, and then fire again.</p> <p>At first I was worried that a node was in trouble, so I checked the cluster for problems:</p> <ul> <li><strong>Cluster status</strong>: Green, no unassigned shards</li> <li><strong>Writes are healthy</strong>: Fluentd&rsquo;s buffer was not piling up and it was not retrying constantly</li> <li><strong>No OOM kills</strong>: the pod restart count did not increase, and <code>Last State</code> was not OOMKilled</li> </ul> <p>All three were fine, so I opened the heap metric. Heap usage was a sawtooth: it kept climbing, dropped, then climbed again. The alert fired right when it reached the peak, and recovered a few minutes later when it dropped.</p> <p>My first thought was to raise the 75% threshold. But since not every cluster fired, it did not look like a threshold problem alone. What confused me more: the other clusters had the same sawtooth, but they dropped at around 60%, while this one climbed to 80% before dropping. Was its configuration different? Was it busier and short on memory?</p> <p>To answer these questions, I first had to understand how the JVM reclaims memory, especially Young GC.</p>https://coder.tw/en/about/Mon, 01 Jan 0001 00:00:00 +0000https://coder.tw/en/about/<p>Hi, I&rsquo;m <strong>Karl Lin</strong> (林熙哲), also known online as linroex. I&rsquo;m a software engineer who likes using technology to solve real-world problems while always keeping business viability in mind. I founded <strong>MoMoKa Studio</strong>, built MICEPLUG, an event management platform that has supported events with tens of thousands of attendees, and worked as a data engineer at 17 Media handling hundreds of millions of records a day. Along the way I have led engineering teams of more than ten people and delivered nearly ten client projects in two years, for clients including CTS News and Seekertech.</p>