DEV Community: Andy Stewart

DeepSeek V4 + Claude Code: Building a "Surgical" Development Workflow with China's Strongest Open-Source Model

Andy Stewart — Mon, 11 May 2026 06:39:43 +0000

The "Vibe Coding" era has evolved. With the release of DeepSeek V4, we finally have an open-source reasoning engine from China that can truly compete with closed-source giants like GPT-4o and Claude 3.5.

As a system architect (founder of deepin and Lazy Cat), I have always pursued determinism and architectural sovereignty. By combining DeepSeek’s logical reasoning with Claude Code’s CLI automation, we can build an AI-native development loop that is extremely low-cost and offers high control.

In just 5 minutes, you can configure this "Terminal Arsenal."

1. The Engine: Installing Claude Code
Claude Code is more than just a chat box; it is an agent running in your terminal that can directly manipulate local files, run tests, and manage Git workflows. It is a true engineering tool.

Microsoft Windows 10:

（1）Press Win+R, type cmd, and open the Command Prompt.

（2）Paste the following code and hit Enter (Note: It must be CMD; PowerShell will not work)：
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
（3）After installation, verify it by running:

claude --version

If the version number appears correctly as shown in the screenshots, the installation is successful.

Note: Pay attention to the small grey text regarding adding environment variables.

Unix (macOS and Linux):

（1）Open your terminal emulator. (macOS users: Search for "Terminal" in Spotlight. Linux users: You know the drill.)
（2）Paste and execute the following code (ensure your network can access global services):
curl -fsSL https://claude.ai/install.sh | bash

（3）Verify the installation:
claude --version

2. The Soul: DeepSeek V4 API

DeepSeek is currently the "smartest brain" with the highest cost-performance ratio globally.

（1） Visit the DeepSeek Open Platform to register.
（2）I recommend an initial top-up (using the flash model is incredibly cheap and perfect for high-frequency iterations).
（3）Generate your API Key.
Safety Tip: I personally store my keys in Bitwarden on my local LCMD private cloud; I refuse to let my data sovereignty go "streaking" on the public cloud.

3. Launch Command: Driving Claude Code with DeepSeek

（1）Using the Anthropic-compatible interface provided by DeepSeek, we can seamlessly swap the underlying model.

（2）Enter the following code in your terminal (replace with your actual Key):

ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic ANTHROPIC_AUTH_TOKEN=sk-你的访问密码 ANTHROPIC_MODEL=deepseek-v4-flash claude

Note: There are spaces in the command—do not miss them. Even a single wrong character will cause it to fail. It is best to copy this into a text editor first, edit it, and then paste it.

4. Real-World Demo: Building a High-Tech Product Page
Once launched, try giving the Agent instructions (using my LC03 project as an example):

"Create an introduction page for LC03. Requirements: White theme, minimalist high-tech aesthetic (Surgical Logic style), optimized for desktop experience. Once written, automatically open the HTML in my browser."

The Workflow: Claude Code will automatically plan the file structure, write the code, and handle permissions. You are only responsible for high-level architectural decisions.

5. Why is this the ultimate solution for the "One-Person Company" (OPC)?
During the development of LightOS (the AI Development All-in-One), I realized that leadership is essentially the quality of the nervous system under pressure. The same applies to tools.

By using Chinese open-source models like DeepSeek, we not only reduce costs but, more importantly, reduce dependency on "external black boxes," keeping the core business logic pure and controlled.

Join the Community
The OPC is no longer a myth. We are deploying AI-generated software directly onto decentralized private hardware, reclaiming digital sovereignty.

Are you ready to move from "writing prompts" to "building systems"? Let's discuss the future of AI infrastructure together.

Breaking the "Desk-Lock": A Linux Veteran’s Blueprint for Walking Programming and Productivity Reconstruction

Andy Stewart — Wed, 06 May 2026 08:55:02 +0000

People call me a "Involution King" (卷王).

They see me managing a company, writing core infrastructure code, and handling a mountain of "miscellaneous" tasks—all while maintaining a relentless release schedule. They’re curious: "Andy, how do you actually ship that much code?"

The answer is simple: I stopped anchoring myself to a desk. I code while walking, while thinking, and while moving. Whether I'm shopping with my wife, walking the dog, or waiting at the school gate, I am in development mode.

For me, this isn't just about efficiency; it's about a seamless transition of roles:

While writing logic, I am the Programmer.

While walking and ideating, I am the Product Manager.

While pushing a release, I am the Project Manager.

I don’t need to be tethered to a physical coordinate. What I need is a systematic architecture—a "plumbing" system that lets me dispatch tasks to AI as digital agents, rather than just staring at a dry chat interface on a smartphone.

The 4 "Hardcore" Pain Points of Mobile Programming
While walking by East Lake or waiting for my daughter after school, I’ve stress-tested nearly every mobile AI coding solution on the market. I’ve realized that true "Programming Freedom" requires overcoming four technical hurdles:

1. Seamless Workflow "Drift" (Context Handoff)
I cannot accept fragmented environments. When I leave my office and head outdoors, my entire coding environment and debugging context must "drift" instantly to my mobile device. The phone isn't a crippled backup; it must share the exact same underlying logic as my workstation.

2. Breaking the "Geofence"
True mobile programming isn't just sitting on your couch. It’s in the car, at the grocery store, or by the BBQ grill. Inspiration is fleeting. You must have the ability to turn a thought into a Commit within 60 seconds of it hitting your brain.

3. Closed-Loop Real-Time Rendering
Programming is fundamentally a loop of "Execute & Verify." Writing code without seeing the result is flying blind. Whether I’m tweaking a UI pixel or refactoring an Agent’s scheduling logic, I demand an instant, live preview of the execution on my actual device.

4. The "Bare Metal" Debugging Advantage
This is the Achilles' heel of most cloud IDEs and web-based AI tools. When you are both the developer and the user, your phone is both your dev machine and your real-world testbed. Validating functions on actual hardware in real-time provides a level of "dev-euphoria" that only hardcore engineers truly understand.

*Field Report: My "Fluid Laboratory" *
Shopping with my wife: Fixing a bug in the Hermes Agent. I’ve already mapped out the logic while walking; during the gaps in our conversation, I whip out my phone, "chat" with the system, modify the code, and verify the fix on the spot.

BBQ by East Lake: Refactoring code amidst the smoke and fire.

Waiting for school pickup: A 15-minute window is more than enough to ship a new version.

The Core Gear: LCMD Micro-Server
The backbone of this entire operation is my LCMD Micro-Server, running 24/7 at my home.

It’s not just a NAS; it’s my Productivity Command Center. You can dispatch heavy-lifting tasks—computational power, environment isolation, and version control—to it at any time, leaving you free to focus on decision-making and high-level planning.

In the past, individuals couldn't handle complex projects because they were trapped by expensive cloud costs and fixed workstations. Now, with a Micro-Server and AI, you can fit an entire development studio in your pocket.

Stop "welding" yourself to your desk. Go walk, go think, and code as naturally as you breathe.

20-Year Linux Veteran Gets "Kernel Panicked"? Hardcore Fix for Random Desktop Freezes on AMD GPUs

Andy Stewart — Thu, 30 Apr 2026 09:22:00 +0000

After 20 years of hacking away in the open-source world and the Linux community, I’ve realized I might actually be a Bug Magnet.

On my previous laptop, a Dell G16, the power-saving mode of the Intel AX201 Wi-Fi card caused pacman updates to crawl at snail speeds. I finally solved that by surgically disabling the power-saving logic. Last year, I switched to this ThinkPad P14s, specifically choosing the AMD integrated graphics version. I thought, "No NVIDIA proprietary drivers to mess with—surely this will be stable, right?"

As it turns out, if you have a mind for "tinkering," bugs will find you with pinpoint accuracy.

The Symptom: The Unavoidable "Frozen Frame"
Recently, my desktop environment started freezing multiple times a day. That feeling of the entire GUI suddenly solidifying is incredibly frustrating. It even made me wonder if I had broken the system by messing with some underlying plumbing.

After work, I decided to cut the Gordian knot and reinstalled EndeavourOS. The freezes persisted. But I noticed a crucial clue: While the GUI was dead, the TTY was still functional. This classic "pseudo-hang" usually means the system hasn't crashed; rather, there’s a communication breakdown between the kernel driver and the hardware.

I fired up dmesg for a deep-dive log review and finally caught the culprit.

[ 4.392040] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 1, DC PSR ver 0, sink PSR ver 3 DPCD caps 0x7b su_y_granularity 4 [ 4.392173] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392327] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392453] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392587] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392641] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392703] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392774] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0 [ 4.392842] amdgpu 0000:c4:00.0: amdgpu: [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
The Root Cause: AMD Driver's PSR Feature
After a technical post-mortem, I discovered the freezes were caused by the Panel Self Refresh (PSR) feature of the AMD Radeon 890M.

This is a known driver bug, particularly prone to triggering on the Ryzen AI 9 HX PRO 370 (Strix Point) platform + amdgpu driver + Plasma desktop combo. PSR is intended to save power by allowing the panel to refresh itself when the image is static, but in practice, it becomes a "chokehold" that causes the GPU driver to hang.

The Surgical Solution: Manually Disabling PSR
For programmers and veterans, the logic for solving problems isn't "reinstalling everything"—it's precise excision. Since the power-saving logic is buggy, we manually disable the feature.

Here is the fix:

1.sudo nano /etc/kernel/cmdline , add the parameter amdgpu.dcdebugmask=0x10 to the end of the line.

2.sudo reinstall-kernels , to regenerate the kernel entries and initrd. This will automatically update all .conf files under /efi/loader/entries/, applying the new parameter to current and future kernels.

3.sudo reboot , restart the system.

Verifying the Kernel Parameters:

Use the command cat /proc/cmdline to check if amdgpu.dcdebugmask=0x10 is present at the end.

You can also run cat /sys/module/amdgpu/parameters/dcdebugmask. If the output is 16 (the decimal equivalent of 0x10), PSR is successfully disabled.

Finally, run dmesg | grep -i psr. You should no longer see any PSR-related logs in the kernel.

After this bit of tinkering, the laptop is now rock-solid. I haven't encountered a single desktop freeze since.

20 Years of Linux Input Method Tweaking: From Kernel Drivers to AI Models—The Ultimate Form of Input Experience

Andy Stewart — Thu, 30 Apr 2026 07:46:34 +0000

Having spent 20 years navigating the open-source world and the Linux community—from building Deepin OS to developing EAF—I’ve always held one conviction: A programmer’s sense of achievement comes half from changing the world, and half from the ultimate refinement of their tools. Many ask me why I still spend so much energy on RIME configurations in the age of AI. It's because an input method is an extension of one's thoughts. Every missed character or mistyped toggle between Chinese and English is a profanity against the "Flow State."

I’ve tested Rime-Ice, Rime-Frost, and Wanxiang, but ultimately returned to Rime-Ice. Wanxiang’s pinyin mode was simply too frustrating due to frequent accidental triggers. Today, I’m organizing all my Fcitx configuration practices into this post. This isn't just a tutorial; it’s a tribute to the open-source community’s spirit of "standing on the shoulders of giants." Since I’ve benefited from the wheels others built, I must contribute my polished solutions back.

If you are an Arch Linux user, congratulations—you don't need to mess with the command lines below. You can simply use my tool, rime-ice-installer, which automatically installs and applies all the configurations mentioned here.

yay -S rime-ice-installer rime-ice-installer

Features of rime-ice-installer:

1.Installs Fcitx and Rime-Ice (Wusong).
2.Automatically configures X11/Wayland environments.
3.Automatically configures the Wanxiang AI Large Model.
4.Configures convenient habits, such as using commas and periods for paging by default.
5.Includes a dark-theme-friendly skin.
6.Most importantly: It maps the Shift key to switch the system's English layout rather than entering Fcitx's internal "English Mode." Once Fcitx's English mode is triggered accidentally, it's notoriously difficult to switch back via the keyboard, often requiring a mouse click on the system tray.

Installing Fcitx5
Install the Fcitx5 packages:

sudo pacman -S fcitx5 fcitx5-gtk fcitx5-qt fcitx5-configtool fcitx5-rime librime

fcitx5: Core input method framework.
fcitx5-gtk: Support for GTK applications. Essential for fixing missing characters during fast typing.
fcitx5-qt: Support for QT5 applications. Essential for fixing missing characters during fast typing.
fcitx5-configtool: GUI configuration tool.
fcitx5-rime: RIME input method engine.
fcitx5-im: Input method setup tool.
librime: RIME libraries, required by emacs-rime below.

Wayland Environment Setup
After installing the packages, in a KDE environment, simply go to KDE Settings -> Virtual Keyboard, select Fcitx5, and log out/in.

For specific apps like WeChat that fail to support Chinese input, you need to create the configuration file ~/.config/plasma-workspace/env/ime.sh and add:

export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS="@im=fcitx"

After logging out and back in, you should be able to type Chinese in WeChat under Wayland.

Notes:
You must install fcitx5-gtk and fcitx5-qt and set the IM variables above, otherwise, typing too fast will result in "character leaking," where the pinyin is inserted directly into the input box instead of converting to Hanzi.

Add-ons: Remove the shortcuts for the clipboard and quick input modules to avoid conflicts with Emacs keybindings.

X11 Environment Setup
For X11, write the following to ~/.xprofile:

export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS="@im=fcitx"

Notes:
Same as Wayland, ensure fcitx5-gtk and fcitx5-qt are installed to prevent character leaking.

Disable clipboard/quick input shortcuts to avoid Emacs conflicts.

Installing Fcitx5 Skins
yay -S fcitx5-skin-adwaita-dark

Then modify the config file ~/.config/fcitx5/conf/classicui.conf:
`Horizontal candidate list
Vertical Candidate List=False

Prevent font scaling with DPI to avoid oversized interface
PerScreenDPI=False

Font and size (check options with fc-list)
Font="Noto Sans Mono 13"

Gnome3-style theme
Theme=adwaita-dark`

Note: I personally prefer "TsangerJinKai03," so you can replace the Font with TsangerJinKai03-6763 15.

Installing Rime-Ice (Wusong Pinyin)
The steps above set up the core and skin, but the default Fcitx dictionary is quite poor. For a fluid experience, you need Rime-Ice.
Copy all rime-ice configurations to the fcitx rime directory:

git clone https://github.com/iDvel/rime-ice --depth=1

Modifying Default Configurations
Switch to the rime-ice directory and perform these three operations:
1.grep all- { when: paging, accept: comma, send: Page_Up } 和 - { when: has_menu, accept: period, send: Page_Down } ，Remove the annotations
2.grep page_size, change 5 to 9.

`sed -i 's/# (- { when: (paging|has_menu), accept: (comma|period), send: Page_(Up|Down) })/\1/' default.yaml

sed -i 's/page_size: 5/page_size: 9/' default.yaml`

he first two enable paging with commas and periods; the third increases the number of candidate words.

Adding Large Language Models
While Rime-Ice is already quite smart, we can enhance context-based suggestions by installing a Wanxiang language model.

The specific operation method is as follows:
Download rime-lmdg. I downloaded the amz-v2n3m1-zh-hans.gram file.

Move the file amz-v2n3m1-zh-hans.gram to the rime-ice directory.

Create a new rime-ice.custom.yaml file in the rime-ice directory with the following contents:

patch: grammar: language: amz-v2n3m1-zh-hans collocation_max_length: 5 collocation_min_length: 2 translator/contextual_suggestions: true translator/max_homophones: 7 translator/max_homographs: 7

Updating the Fcitx Directory
After adjusting the configs, perform the copy. Backup and clear ~/.config/fcitx/rime/ and ~/.local/share/fcitx5/rime first to avoid conflicts.

cp -r ./rime-ice/* ~/.config/fcitx/rime/ cp -r ./rime-ice/* ~/.local/share/fcitx5/rime

~/.config/fcitx/rime/: Primarily read by the emacs-rime plugin.

~/.local/share/fcitx5/rime: Read by Fcitx for external software.

Deleting Accidental Input
If you accidentally confirm a pinyin string, it might become the first candidate. These are recorded here:

~/.local/share/fcitx5/rime/en_dicts/en.dict.yaml ~/.config/fcitx/rime/en_dicts/en.dict.yaml
Find the errant string, delete it, save, and restart Fcitx.

Installing emacs-rime
This section is about bringing Rime-Ice into Emacs.
First, install posframe, and then download emacs-rime:

git clone https://github.com/DogLooksGood/emacs-rime

Add the directory to your load-path and add the following config:

`(require 'rime)

;;; Code:
(setq rime-user-data-dir "~/.config/fcitx/rime")

(setq rime-posframe-properties
(list :background-color "#333333"
:foreground-color "#dcdccc"
:font "WenQuanYi Micro Hei Mono-14"
:internal-border-width 10))

(setq default-input-method "rime"
rime-show-candidate 'posframe)`

The configurations above respectively set the path for emacs-rime to read RIME configurations, the UI details, and the use of posframe to display candidate words.

After restarting Emacs, invoke the toggle-input-method command to try typing in Chinese.

The Rime-Ice home page provides several input examples. If typing the same pinyin yields the identical Chinese candidate words, it confirms that you have successfully implemented Rime-Ice.

In my personal experience, the fine-tuning of Rime-Ice is exceptional—far more professional than any RIME dictionary I’ve tried to cobble together myself. Chinese input, especially for long sentences, no longer requires flipping through endless pages of candidates.

The combination of emacs-rime and Rime-Ice makes Chinese input in Emacs an absolute joy. I’ve personally sent a small donation to the author of Rime-Ice to show my appreciation for their hard work and contribution to the open-source community！

Farewell to F5: Building a Seamless Writing Workflow with Jekyll LiveReload

Andy Stewart — Wed, 29 Apr 2026 09:07:10 +0000

As a 20-year Linux veteran, I have zero tolerance for mechanical tasks that break my "flow."

When using Jekyll for blogging, many developers fall into a repetitive trap: edit a paragraph -> switch to the browser -> hit manual refresh (F5). It’s a tiny friction, but like a memory leak in your code, it slowly drains your creative energy throughout the day.

The solution has been hiding in the Jekyll documentation all along.

1. The Core Command: Instant Synchronization
Stop using the plain jekyll serve. Instead, fire up your local environment with this:

Bash jekyll serve --livereload

By adding this parameter, Jekyll spins up an internal listener. The moment your Markdown file is modified and saved, the browser updates the view automatically, as if it’s reading your mind.

2. My Hardcore Workflow: Emacs + Hammerspoon + Magit
Configuring LiveReload is just the foundation. Real efficiency comes from automating the entire pipeline. Here is my "zero-friction" loop—designed so that the moment my fingers leave the keys, everything is already in motion:

Drafting in Emacs: Writing fluidly in markdown-mode.

Auto-Save: My auto-save plugin commits the changes to the disk the split-second I stop typing.

Invisible Refresh: Jekyll detects the change immediately. I use Hammerspoon to snap to the browser, where the content is already rendered and waiting for me.

Magit Deployment: Once I'm satisfied with the preview, a few quick Magit keystrokes push the update straight to GitHub Pages.

A developer’s dignity is reflected in the craftsmanship of their toolchain. Achieving this kind of "seamless transition" allows you to pour 100% of your focus into the content itself, rather than acting as a manual bridge between your editor and the browser.

What "manual refresh" or repetitive task in your daily workflow drives you crazy? How did you use scripts or automation to kill it off for good?

Share your efficiency secrets or your Jekyll optimization tips in the comments below.

$400 or $4? Using 'Surgical Logic' for a Hardcore MacBook Keyboard Repair

Andy Stewart — Wed, 29 Apr 2026 06:47:43 +0000

As a long-time Linux enthusiast and a heavy hitter on the keys, I’ve always been fascinated by the underlying architecture of our tools. Recently, my MacBook Pro met its match—I managed to physically break one of the keycaps.

A quick trip to the Apple Store ended with a quote that made my jaw drop: $400 to replace the entire top case assembly. For a hacker used to "building and breaking," this didn't sit right. I decided to embrace the DIY spirit and handle it myself.

I spent about 30RMB ($4) buying a full set of replacement keycaps from Taobao.com. I thought this was going to be a "level 1" repair, but a single mistake quickly turned it into a "boss fight."

The Incident: A Lesson in Chemistry and Adhesives
At first, I thought only the keycap was broken. After a failed attempt to force it back on, I realized the butterfly hinge underneath was damaged. In a moment of misplaced confidence, I grabbed a bottle of Super Glue (502).

The second that drop hit the board, I knew I had messed up. Super glue is fast-acting, low-viscosity, and highly corrosive to certain plastics. It didn't just bond the hinge; it seeped into the base and melted the precision elastic membrane responsible for the key's tactile feedback.

The result: The 'J' key was dead. No travel, no click, just a solid block of plastic. This is what happens when you ignore the physical properties of your materials.

Structural Analysis: The Precision of the Butterfly Design
Since I had already "bricked" the base, I decided to perform a full "autopsy" to understand the mechanics. Despite the frustration, the engineering is remarkably sophisticated:

Logic Board (PCB): The bottom layer, handling circuitry and LED backlighting.

Butterfly Hinge: Two interlocking wings that sit between the PCB and the base.

The Base: The critical component. It snaps into four tiny notches on the PCB, holds the hinge in place, and houses the metal dome for tactile feedback.

Keycap: The outer shell that clips onto the top of the hinge.

The tolerances here are incredibly tight. Even a microscopic amount of excess glue can paralyze the entire movement.

Tooling Up: Finding the Perfect "Surgical Glue"
To fix the melted base, I needed an adhesive that met three hardcore requirements:

Needle-fine Applicator: Total control at the millimeter level to avoid the contact points.

Material Safety: Non-corrosive to delicate plastics.

Slow-Curing: Allowing time for precise alignment and error correction.

I eventually found B7000, a specialized adhesive used in smartphone repairs. Its needle-nose tip allowed for the precision I desperately needed.

The Ultimate $4 Fix (Step-by-Step)
Materials Required:
Replacement Base + Hinge ($2)
New Keycap ($1)
B7000 Adhesive ($1)

The Repair Process:

1.Debridement: I used tweezers to painstakingly peel off the damaged, glue-crusted base from the PCB.

2.Precision Grouting: I applied three tiny dots of B7000 (about 2mm wide) on the PCB, strictly avoiding the center sensor and the top LED.

3.Assembly: I snapped the hinge into the new base first, then aligned the base with the four PCB notches and pressed down.

4.Verification: I tapped the center of the base to ensure the character appeared on the screen with a clean rebound.

5.The "Cure" (Crucial!): Do not snap the keycap on yet. Wait several hours for the glue to fully cure. If you try to snap the keycap on too early, the vertical pull will rip the base right off the board.

6.Final Marriage: Once cured, I snapped the keycap on with a satisfying click.

This experiment taught me that modern hardware is a marvel of integration, where even a tiny key carries immense complexity. While the journey was chaotic, it proved a point: There is no machine that cannot be fixed, provided you understand its logic.

Faced with a $400 repair bill, I chose a $4 fix and a heavy dose of curiosity.

Have you ever had a "minor" repair turn into a major disaster, only to pull off a hardcore recovery in the end? What’s the most "dangerous" thing you’ve ever done to your daily driver?

Stop Backspacing Like a Typist: My "Surgical" Syntax Deletion Tool for Emacs

Andy Stewart — Wed, 29 Apr 2026 03:40:44 +0000

I’ve always believed that a hardcore developer shouldn't waste a single second on low-level chores like "deleting code."

In Emacs, most people delete code by either mashing the Backspace key like they're tapping out Morse code, or using kill-word only to find they’ve overshot and deleted half the expression. While subword-mode fixed navigation for CamelCase, deletion still lacks that critical sense of determinism.

I wanted a tool that combines the raw power of skip-syntax with the granular intelligence of subword-mode. So, I built a plugin for what I call Syntax Block Deletion.

Why "Surgical" Precision Matters
Standard deletion relies on whitespace or generic word boundaries. This tool operates on the logic of your code. By tapping directly into Emacs' internal syntax tables, it achieves a "what you see is what you prune" experience:

Subword Awareness: When it hits FooBarExample, it recognizes Foo, Bar, and Example as distinct entities. You can snip away** Bar** without touching the rest.

Syntax Boundary Intelligence: It automatically senses operators, delimiters, and symbol boundaries. It knows exactly where a logical unit ends, so it won't go charging through your parentheses like a blunt instrument.

Zero-Latency Feedback: Built on low-level syntax skipping, the response is instantaneous. No bloat, just speed.

Arm Your Editor
The implementation is lean and mean. I recommend binding these to your most accessible keys to completely replace your default deletion commands:

delete-block-forward: Instantly prune the next syntax block.

delete-block-backward: Precisely detonate the previous logical unit.

When you're building complex systems like EAF, these micro-efficiencies compound into massive productivity gains. Every keystroke should be deliberate. If you’re still tolerating the uncertainty of "I wonder how much this keypress will delete," your toolchain is overdue for a refactor.

Let's start a discussion:
In a world of highly customizable editors, what other "high-frequency" actions do you think are still fundamentally broken or inefficient? What "secret weapons" have you hidden in your own config to maintain your flow?

See you in the comments, and I'm looking forward to your PRs.

GitHub Repository: [((https://github.com/manateelazycat/delete-block))]

Happy Hacking!

20-Year Linux Veteran: How I Slashed My Emacs Startup Time by 90%

Andy Stewart — Wed, 29 Apr 2026 03:30:17 +0000

As a long-time contributor to the Emacs community and the creator of EAF (Emacs Application Framework), I’ve always maintained one rule: If your development tool takes more than 2 seconds to start, it’s murdering your creativity.

Many developers complain that Emacs is "bloated," but the truth is usually just poorly architected configuration. Today, I’m skipping the fluff and sharing my hard-earned methodology for optimizing startup performance. By following these three steps, you can compress your startup time to 1/10th of what it is now.

1. Stop Guessing: Benchmark Your Config
The first rule of optimization: If you can't measure it, you can't improve it.

Don't blindy disable packages. Insert the following code at the very top of your configuration to use benchmark-init. This recursively analyzes the overhead of every single line in your setup.

`Code snippet
(let (
;; Temporarily set GC threshold to infinity to prevent garbage collection during startup
(gc-cons-threshold most-positive-fixnum)
;; Clear file-name-handler-alist to skip regex matching on every loaded file
(file-name-handler-alist nil))
(require 'benchmark-init-modes)
(require 'benchmark-init)
(benchmark-init/activate)

;; Your core configuration goes here
)After startup, runM-x benchmark-init/show-durations-tree`. This gives you a precise, millisecond-level "hit list" showing exactly which packages are slowing you down.

2. Dynamic Decoupling: Don't Load What You Don't Use
This is a fundamental architectural shift. Many libraries are only needed for specific scenarios—why let them clog your startup path?

Take the noflet library, often used to suppress the "Active processes exist" query when quitting:

The Inefficient Way:

Code snippet (require 'noflet) ;; Loaded at startup, even if you don't quit for days (defadvice save-buffers-kill-emacs (around no-query-kill-emacs activate) (noflet ((process-list ())) ad-do-it))

The Hardcore Way (On-Demand Loading):

Code snippet (defadvice save-buffers-kill-emacs (around no-query-kill-emacs activate) "Only load the library at the moment the exit command is triggered" (require 'noflet) (noflet ((process-list ())) ad-do-it))
By moving require inside the function or using eval-after-loadblocks, you can strip away 50% of unnecessary dependencies from your initial boot.

3. The Ultimate Weapon: Lazy-Loading via Key Triggers
This is my core secret. The logic is simple: Defer the loading of 90% of your plugins until the moment you actually press the key to use them.

The traditional approach is "Load, then Bind." My lazy-load technique flips this: "Bind, then Inject."

At Startup: Only define the keybindings (e.g., Ctrl + c p for project management).

At Runtime: The moment you hit that key, Emacs injects the source code and executes the command instantly.

This reduces your startup process to a list of pure key mappings—the leanest possible configuration.

Top-tier developers demand two things from their tools: determinism and extreme responsiveness.

Optimization isn't about removing features; it's about precise resource allocation. Save your startup time for the work that matters, and keep your "flow" uninterrupted. If you're chasing terminal efficiency, try refactoring your config with these three steps today.

Happy Hacking!

Lightweight Analytics for Jekyll: Why I Chose Hit Kounter Over Google Analytics

Andy Stewart — Tue, 28 Apr 2026 09:31:22 +0000

Privacy and Speed First
As I continue to polish my Jekyll blog on GitHub Pages, I realized I needed one more thing: View Counts. I wanted to know which topics resonate most with my readers, but I had two strict requirements:

No Google Analytics: I don't want my site to be blocked or slowed down by heavy tracking scripts (especially considering accessibility in different regions).

Minimalist Integration: It should be as "plug-and-play" as Jekyll itself.

After searching, I found Hit Kounter. It’s simple, fits perfectly with static sites, and just works.

How to Set It Up in 2 Minutes
1. The Header Injection
First, you need to include the Hit Kounter script in your HTML <head>. Usually, this goes into your_includes/head.htmlfile:

HTML <script src="https://cdn.jsdelivr.net/npm/hit-kounter@0.1.0/dist/hit-kounter.js"></script>

2. Displaying Views on Post Pages
To show the view count for a specific article, just add this tag to your post template (e.g., _layouts/post.html):

HTML <span data-hk-page="current"> - </span> Views

The current attribute automatically detects the current URL.

3. Displaying View Counts on the Homepage
If you want to show the traffic for each post on your homepage index, use this snippet in your index.html loop:

HTML <span data-hk-page="{{ post.url | prepend: site.url | prepend: 'https:' }}"> - </span> Views

Pro Tip: Hit Kounter requires the absolute URL to track accurately. That’s why we use prepend: site.url and ensure https: is explicitly added. Without the full protocol, the counter won't trigger.

That’s All!
Just git push and your analytics are live. No complex dashboards, no privacy concerns, just a clean, simple number that tells you what your audience loves.

It’s another small step toward building the perfect minimalist writing environment.

What are you using to track your static site? Are you a fan of self-hosted analytics or do you prefer these "Zero-Config" tools? Let me know in the comments!

About the Author:
I am Yong Wang, a 20-year Linux veteran and former CTO of Deepin. I’m currently building Little Chinchilla, an AI Agent host designed for private-domain computing. Catch me on GitHub where I spend most of my time hacking Emacs.

Why Jekyll + GitHub Pages is the Ultimate Sanctuary for Minimalist Developers

Andy Stewart — Tue, 28 Apr 2026 09:22:32 +0000

The Return of the Creative Spark
After migrating my blog to GitHub Pages, I felt a long-lost surge of creative desire. The reason is simple: Jekyll, the engine behind GitHub Pages, perfectly aligns with my philosophy of software and life.

As a developer who has spent two decades in the Linux trenches and countless hours in Emacs, I don’t want to be bogged down by database migrations, VPS maintenance, or clunky web editors. I want to write.

Here is why Jekyll won me over:

Zero Infrastructure: No databases, no servers. Everything lives on GitHub. It’s free, stable, and "set and forget."

Markdown + CSS Synergy: I get the zen-like simplicity of Markdown combined with the total control of CSS. I can fine-tune every detail—from zebra-striped tables to the exact border-radius of a code block.

Content-First Workflow: Once the theme is defined, my workflow is just: write -> git push. That’s it.

Local Real-time Preview: One command—jekyll serve—and I can see exactly how my thoughts look in the browser.

Emacs Integration: This is the deal-breaker. I don't need a browser-based editor. I write everything in Emacs. It’s fluid, fast, and familiar.

My Custom CSS Hacks for a Modern Static Blog
To make a static blog feel modern and professional, you don't need heavy frameworks. You just need a few clever CSS rules. Here are the snippets I use to polish my reading experience:

1. Responsive Image Scaling
Screenshots and photos come in all sizes. To prevent them from breaking the layout, I force them to scale gracefully with the page width:

CSS li > img, p > img { margin: 0 auto; display: block; max-width: 90%; margin-top: 5px; margin-bottom: 5px; margin-left: 2em; margin-right: 2em; border-radius: 5px; }
2. Elegant Centered Tables
Standard Markdown tables are often left-aligned and look awkward. Centering them makes the page feel balanced:

CSS table { border-collapse: collapse; border-spacing: 0; border: 1px solid #AAA; margin-left: auto; margin-right: auto; }
3. Zebra-Striped Rows
Reading large tables is a nightmare without visual cues. A subtle zebra stripe makes data much more digestible:

CSS tbody tr:nth-child(even) { background-color: #F5F5F5; }
4. "Soft" Code Blocks
Code is the soul of a developer's blog. Default sharp corners create visual tension. Adding a small border-radius makes the code area feel more natural and easier on the eyes:

CSS div.highlight, pre.highlight { border-radius: 5px; }

For me, Jekyll is more than just a static site generator. It’s about creating a focused writing environment.

It allows me to achieve visual perfection with minimal overhead while maintaining maximum editing efficiency. It’s fluent, comfortable, and keeps me in the zone.

How about you? Are you still fighting with WordPress or Medium, or have you embraced the "Git-based" blogging lifestyle? If you are an Emacs user like me, I'd love to hear about your blogging setup in the comments!

About the Author:
I am Yong Wang, a 20-year Linux veteran, Emacs lover, and former CTO of Deepin. I’m currently exploring the intersection of AI Agents and private computing with my new project.

I Built China’s Top Linux OS, Handed it to Linus Torvalds, and Then I Had to Walk Away

Andy Stewart — Tue, 28 Apr 2026 08:15:20 +0000

In the open-source world, many know Deepin Linux. It is the distribution that dared to build an oasis in the Linux desert—obsessed with aesthetics, seamless user experience, and a unique desktop environment built from the ground up.

I am Yong Wang, the co-founder and former CTO of Deepin, and a 20-year Linux veteran. In 2019, I decided to leave the battlefield I spent eight years building and return to being a pure developer. Before I start my next journey, I want to share the "hardcore" story of growing from a single developer to a 1,000-person team—and why, at the peak of it all, I was forced to walk away.

1. 2011: Adrenaline, GTK+, and "Square Wheels"
In 2011, Deepin was just a "garage startup." Our office was a tiny 70-square-meter room with second-hand chairs, bright red carpets, and the sounds of developers howling like wolves at 3:00 AM as they cracked a difficult bug.

Back then, the Linux desktop felt like a wasteland. The "wheels" were all square: cryptic configurations and monotonous grey native controls. I couldn’t stand seeing users struggle with poorly designed software. We wanted to build wheels that were round and smooth.

One crazy memory: In late 2011, just 20 days before the release of version 11.12, our CEO suddenly suggested we ditch Gnome 2 for the brand-new Gnome 3. Any rational team would have said no. But we only had courage. I led the team to crank out 10,000 lines of code in 20 days—an average of 500 LoC per day. When we saw the Deepin logo flash onto the screen for the first time, the sense of achievement was, for us, equivalent to the moon landing.

2. Brothers in the Trenches: Passion Over Code
In the early days, we had no biological clock. We’d nap with our heads hanging over our chairs and wake up to keep coding. Once, the entire R&D team didn't go home for three weeks straight.

I remember a bet I made with "Monkey," the author of Deepin Music. He scoffed and said I couldn't build a complex list control in time. For that, we stayed in the office for over 30 hours. He was chain-smoking, and I was smashing the keyboard. At 6:00 AM the next day, the code merged perfectly. We went to a barbershop with greasy hair just to get a quick wash, then came right back to work.

Collaboration in the open-source community is that pure: a shared dream + a reliable team equals more motivation than any corporate system.

3. The Peak: From 100M Funding to Linus Torvalds’ Hands
By 2015, we had secured roughly $12 million in funding. But for the technical team, the real "medal of honor" didn't come from investors—it came from the creator of Linux himself.

*The moment Linus Torvalds experienced Linux Deepin *

One of our proudest moments was handing a laptop pre-installed with Deepin to Linus Torvalds. Watching the "Godfather of Linux"—who is famously picky about his desktop environments—personally experience and navigate the UI we built from scratch was surreal. At that moment, Deepin wasn't just a local project anymore; it had reached the global stage.

But as we moved into a high-end, 2,000-square-meter office and the team swelled toward 1,000 people, the "nursing home" vibe began to set in. I realized that once communication distance increases, a high-performance team can quickly become mediocre. I had to stop my compiler and learn how to manage, but the growing scale began to suffocate the very creativity that brought us to Linus's hands.

4. Why I Left: A Forced Farewell
By 2018, Deepin supported 70 languages with over 50 million downloads worldwide. To the outside world, this was the peak. To me, it was a long, painful "forced downgrade."

I discovered that as a company evolves into a massive machine, pure technical ideals are diluted by complex interests, power plays, and bureaucracy. I was no longer the CTO who could hack all night; I had become a business machine, exhausted by endless meetings and carrying the weight of organizational "blame."

I thought we would fight together forever, but the influx of capital and the sheer scale turned simple camaraderie into something complicated. The suffocating feeling of "wanting to do the right thing but having no power to steer the ship" eventually forced me to make that painful decision. I left a cause I thought I would fight for my entire life. This departure was partly a proactive choice to preserve my sanity, but mostly a forced exit pushed by reality. I couldn't take Deepin with me, but I took my conscience as a developer.

To all the geeks out there:
Entrepreneurship is essentially a journey to understand yourself more deeply. While the world is chasing the "next big trend," look down at the code in your hands.

If you feel pain on the path to your ideals, remember: that is the sound of the system undergoing a "kernel upgrade" under extreme pressure.

About the Author:
I am Yong Wang, former CTO of Deepin and a 20-year Linux developer. I am currently starting fresh with my new project (小龙猫), focusing on private-domain AI computing hardware.

If you've experienced the collision between ideals and reality, or if you're interested in Linux architecture and AI Agents, let’s connect in the comments!

From Stochastic Drifting to Vector Anchors: How I Solved Voice Consistency in Qwen TTS

Andy Stewart — Mon, 27 Apr 2026 09:15:17 +0000

Stop relying on seeds. Learn how to implement deterministic persona via vector constraints.

I’ve spent the last 72 hours deep in the trenches of Qwen TTS (Text-to-Speech) technology. After three days of high-intensity parameter deduction and experimentation, I’ve finally cracked a problem that has been a nightmare for many: Cross-sentence voice stability.

If you’ve tried to narrate a long text with AI, you know the frustration. You find a perfect voice for the first sentence, but by the third sentence, the AI has "morphed" into a different person.

Here is the architectural breakdown of why this happens and how to fix it using what I call the "Vector Anchor" method.

1. The "Seed" Fallacy
Early in my investigation, I focused on the seed parameter. In traditional generative systems, a seed implies reproducibility. However, in the context of Qwen’s latent space, its utility is strictly scoped:

What Seed does: It ensures that the exact same text produces the exact same audio (even the MD5 hashes will match).

Where Seed fails: As soon as you change the input text—even by a single character—the seed’s constraint collapses. The model’s "vocal cords" drift, and the persona shifts randomly.

Architectural Insight: A seed is a snapshot of an inference sequence, not a persistent identity. Relying on seeds for cross-sentence stability is a dead end.

2. Tone Instructions vs. Identity Definition
Qwen’s natural language tone instructions (e.g., "make it thicker," "cleaner," "more mature") are brilliant, but they are personality modifiers, not identity definitions. They adjust the "texture" of the voice but cannot lock the underlying persona across different text inputs.

To achieve industrial-grade stability, you need a physical anchor.

3. The Solution: The Vector Anchor Workflow
The only way to achieve true deterministic output in Qwen TTS is through Voice Cloning via Vector Constraints. Here is the 3-step logic I verified:

Step 1: The Persona Hunt
Use tone instructions and seeds to iterate. If a voice is too "girly," instruct it to be "cleaner and more professional." If a male voice is too thin, add "depth and weight." Keep iterating until you hit that "Perfect Sample."

Step 2: Feature Extraction
Export that perfect generation as a .wav file. This is no longer just "audio"; it is now your Source of Truth.

Step 3: Hardening with .pt Files
Use the Qwen interface/API to generate a .pt file (speaker embedding) from that WAV.

Think of the .pt file as a Vector Anchor.

It acts as a deterministic constraint on the model's latent space.

By passing this file as a reference for every subsequent sentence, you "force" the model to stay within the specific vocal coordinates of your persona.

The "Double-Layer" Control
The most fascinating part of this architecture? Once the identity is locked via the .pt file, tone instructions still work.

You can maintain a stable persona (Identity A) while using secondary instructions to change the mood (excited, somber, whispered). You get a consistent narrator who can actually act.

The Architect’s Takeaway: Truth Comes from Practice
After three days of stress-testing these parameters, the result is incredibly natural—a narrator that sounds human, consistent, and professional.

In this AI era, we may find ourselves writing fewer lines of manual code, but the demand for logical deduction and system orchestration has never been higher. Models are black boxes, but parameters follow logic.

As I always say: Truth comes from practice. You don’t know how a system breathes until you’ve pushed its boundaries yourself.

Hopefully, this architectural shortcut saves you the three days of wandering I went through.

Have you encountered voice drift in your TTS workflows? How are you handling identity persistence in generative models? Let’s talk in the comments.