<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Alienchow</title><link>http://alienchow.dev/post/</link><description>Recent content in Posts on Alienchow</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 29 Mar 2026 12:26:48 +0800</lastBuildDate><atom:link href="http://alienchow.dev/post/index.xml" rel="self" type="application/rss+xml"/><item><title>AI Hot Takes From A Platform Engineer / SRE</title><link>http://alienchow.dev/post/ai_takeaways_mar_2026/</link><pubDate>Sun, 29 Mar 2026 12:26:48 +0800</pubDate><guid>http://alienchow.dev/post/ai_takeaways_mar_2026/</guid><description>&lt;p>A blip appeared on my phone while I was on the treadmill last week, it was yet another LinkedIn post talking about the wonderful value AI has brought upon us. Day after day, anywhere I look, I have to sit through opinions that are exuberantly optimistic. Yet all examples given are always tiny tools, and I have yet to see a real-world example of agentic usage in production critical systems that hasn&amp;rsquo;t gone wrong, or at best underperforming.&lt;/p></description></item><item><title>My Home Fibre Network Disintegrated, Literally</title><link>http://alienchow.dev/post/fibre_disintegration/</link><pubDate>Sun, 11 Jan 2026 11:11:50 +0800</pubDate><guid>http://alienchow.dev/post/fibre_disintegration/</guid><description>&lt;hr>
&lt;blockquote>
&lt;p>Thanks HN folks for all the comments. To clarify a bit, the cables are pulled through PVC conduits under the flooring before being buried in cement. Currently the hypothesis for why the cable disintegrated so quickly is hydrolysis. Singapore is extremely humid after all. A second possibility is that I keep the leftover wall paints (&lt;a href="https://nipponpaint.com.sg/product/vinilex-5000/">Nippon Paint Vinilex 5000&lt;/a>) in the same room and have noticed that much of the solvents have evaporated. It is possible that the solvents in the air might have caused the cable to fail in 3 years. The other ends of the cables don&amp;rsquo;t feel as sticky and crumbly despite being out in the open exposed to the humidity. My guess is that the paint solvent got to it.&lt;/p></description></item><item><title>Back Strain is Gone</title><link>http://alienchow.dev/post/backstrain_gone/</link><pubDate>Sat, 10 Jan 2026 00:47:29 +0800</pubDate><guid>http://alienchow.dev/post/backstrain_gone/</guid><description>&lt;p>To my child.&lt;/p>
&lt;p>This week, I showered you while watching you play with your shower toys. As usual, you refused to cooperate, insisting on filling the tiny stacking cups with water before wasting copious amounts of shampoo into the cup to create bubbles. As you dipped your tiny fingers in to smear the bubbly foam all over the bathroom walls to create your latest soapy murals in glee, I rinsed off the shampoo on your head. You held your breath and closed your eyes, as would anyone else when soapy water flowed down their face.&lt;/p></description></item><item><title>Project Homelab - Part 1: Laying the Foundation</title><link>http://alienchow.dev/post/homelab1/</link><pubDate>Mon, 15 Sep 2025 00:46:47 +0800</pubDate><guid>http://alienchow.dev/post/homelab1/</guid><description>&lt;h2 id="planning-a-future-proof-home-network">Planning a Future-Proof Home Network&lt;/h2>
&lt;p>Around early 2022, I finally received the keys to my &lt;a href="https://en.wikipedia.org/wiki/Build_to_order_(HDB)">BTO&lt;/a> flat in Singapore. The whole construction project was delayed by a year due to COVID-19, resulting in a total wait time of 5 years. As our family was still residing in Switzerland back then, we flew back to Singapore for 6 weeks just to deal with planning the renovations.&lt;/p>
&lt;img src="http://alienchow.dev/images/homelab1/barebones.jpg" width="" height="" alt="absolutely bare flat">

&lt;p>As shown in the photo, there was absolutely nothing. We had opted out of all of the government-offered packages in order to design our new home from scratch. This gave me the very rare opportunity of planning my home network infrastructure exactly the way I wanted it.&lt;/p></description></item><item><title>《虑》</title><link>http://alienchow.dev/post/lone/</link><pubDate>Sat, 09 Nov 2024 13:23:59 +0800</pubDate><guid>http://alienchow.dev/post/lone/</guid><description>&lt;p>孤愁瞻逐妄&lt;/p>
&lt;p>履践绕居频&lt;/p>
&lt;p>与友焦谈饮&lt;/p>
&lt;p>终究蜃景鸣&lt;/p></description></item><item><title>RCU is Pretty Cool</title><link>http://alienchow.dev/post/rcu/</link><pubDate>Sat, 02 Nov 2024 07:35:11 +0800</pubDate><guid>http://alienchow.dev/post/rcu/</guid><description>&lt;h2 id="do-you-know-what-is-read-copy-update">&amp;ldquo;Do you know what is read-copy-update?&amp;rdquo;&lt;/h2>
&lt;p>&lt;a href="https://www.linkedin.com/in/balazs-dezso/">Balázs&lt;/a> randomly mumured on a Friday
afternoon while I was doom scrolling the endless stream of despair on Memegen
some time shortly after the
&lt;a href="https://blog.google/inside-google/message-ceo/january-update/">Jan 2023 layoffs&lt;/a>.
Friday wasn&amp;rsquo;t one of the team designated RTO days, but I decided to work from
office anyway for some focus time, as few people would be coming in.&lt;/p>
&lt;p>&lt;em>&lt;strong>B: &amp;ldquo;It&amp;rsquo;s pretty cool.&amp;rdquo;&lt;/strong>&lt;/em>&lt;/p>
&lt;p>Balázs proceeded to explain to me that read-copy-update, or RCU, is a lock-free
mechanism to update data structures that are actively being consumed by
asynchronous readers without the usage of locks. It was first introduced into
the Linux kernel
&lt;a href="https://mirrors.edge.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.43">back in 2002&lt;/a>,
but discussions and designs date back to the
&lt;a href="https://worldwide.espacenet.com/patent/search/family/022246250/publication/US5442758A?q=pn%3DUS5442758">mid 90s&lt;/a>.
The general idea is that instead of applying a mutex lock to update an
asynchronously read data structure, instantiate a copy of the existing data
structure and apply changes to the new instance. After the changes are applied,
do an atomic update of the pointer from the old instance to the new one. This
essentially creates a lock-free update of data change.&lt;/p></description></item><item><title>Debugging SRE #2: Pager Burnout</title><link>http://alienchow.dev/post/pager_burnout/</link><pubDate>Fri, 01 Nov 2024 00:00:00 +0800</pubDate><guid>http://alienchow.dev/post/pager_burnout/</guid><description>&lt;img src="http://alienchow.dev/images/this_is_fine.jpg" width="" height="" alt="this is fine">

&lt;p>It goes without saying that even the most disciplined SRE functions eventually
experience pager burnout. Over time, I&amp;rsquo;ve found that the reasons can be
condensed down to 4 main reasons:&lt;/p>
&lt;ul>
&lt;li>Lack of pager review&lt;/li>
&lt;li>Undersized teams&lt;/li>
&lt;li>Incompatible on-call shift length&lt;/li>
&lt;li>Inadequate on-call compensation&lt;/li>
&lt;/ul>
&lt;h2 id="pager-review">Pager Review&lt;/h2>
&lt;h3 id="treat-a-page-like-a-page">Treat a Page Like a Page&lt;/h3>
&lt;p>The most mindblowing thing to me was seeing teams use Slack notifications as a
pager alert.&lt;/p>
&lt;p>Repeat after me:&lt;/p></description></item><item><title>Debugging SRE #1: SOP Opera</title><link>http://alienchow.dev/post/sop_opera/</link><pubDate>Thu, 31 Oct 2024 00:00:00 +0800</pubDate><guid>http://alienchow.dev/post/sop_opera/</guid><description>&lt;h2 id="reliability-theatrics-galore">Reliability Theatrics Galore&lt;/h2>
&lt;p>Recently, I have observed several anti-patterns going on in teams:&lt;/p>
&lt;ul>
&lt;li>Release engineer accidentally skipping a step during deployment causing an
incident.&lt;/li>
&lt;li>No one knew how to roll back a service because no one knew where the SOP was.&lt;/li>
&lt;li>Action items in the post-mortem reports added more manual checks to the
ever-growing checklist&lt;/li>
&lt;/ul>
&lt;p>The recurring theme in all the above is the over reliance on Standard Operating
Procedures (SOP). SOP has its place for basic sanity checks and release
approvals, but several teams have been using it as a crutch to weasel out of
building scalable, long-term solutions.&lt;/p></description></item><item><title>Debugging SRE</title><link>http://alienchow.dev/post/debugging_sre/</link><pubDate>Sat, 26 Oct 2024 00:00:00 +0800</pubDate><guid>http://alienchow.dev/post/debugging_sre/</guid><description>&lt;p>&lt;code>Debugging SRE&lt;/code> is a series of low effort brain dumps, consisting of reliability
practices that I have observed, and to discuss anti-patterns masquerading as
reliability diligence.&lt;/p>
&lt;p>After resigning from the Google tech island to practise Site Reliability
Engineering (SRE) elsewhere, I have come to realise that many organisations
fancy the branding and engineering credibility of a tech organisation that has
a dedicated SRE team.&lt;/p>
&lt;p>Yet, few of the organisations that I&amp;rsquo;ve observed so far actually embrace the
full implementation of an SRE function. Many are just rebranded DevOps or IT
Sysadmins. More concerningly, some of these SRE orgs are made up of traditional
Ops Engineers who barely know how to code beyond copy pasting Bash or Powershell
scripts. The premise of the original Google SREs was to have SWEs work on ops
using software development perspectives, so as to bridge the divide between Dev
and Ops to focus on service stability.&lt;/p></description></item></channel></rss>