DEV Community: Vincent Yang

The Internet is a Thin Cylinder: Supporting Millions, Supported by One

Vincent Yang — Thu, 02 Apr 2026 00:00:00 +0000

The internet is not always a busy place full of charm, but that is only
a blink of it.

The other places? Either no one knew it existed, or the only thing that
knew it was the bots.

Why is this an actual thing?

You might have been thinking, how could this happen? As of 2026, there
are at least 1 billion websites, and if all these just have a few links
to another, everyone should be able to see and visit them.

But this is not the case, the reason is not because people cannot find
it, it is because they ignored it, because the site had been flushed
away by the high-speed development of the Internet.

Some of the sites and tools might be a legendary in the past. But after
new tools and technology came in, it is quickly forgotten, only leaving
the few people quietly maintaining it.

An example of this

There are millions of examples of old websites that have been forgotten
by time. We can take the GNU project Nano as an example that is fairly
neutral, not too active, but not completely dead.

It is not a dead project; in fact, it is quite active. But active does
not mean it has a big community; few people can create an active
environment via just creating code, but few people cannot create charm
as it requires not just the code.

If you look at the git log of Nano or the mailing list, you will find
out that the only person that is really contributing to the project a
lot is the maintainer.

And this project is the text editor that millions of programmers every
day, a very important tool that I also use a lot of in. I am very
thankful that its creator created it, maybe at the time, they never knew
that it's going to be this big.

I am not saying that this is not good, or anything I mentioned in this
post. Sometimes these projects are just "finished", and there are
seldom bugs; a few people are enough for it to continue. Or working
alone is what people prefer, including me.

I chose this project as an example, not because it is the worst. There
are thousands of projects that have no one maintaining, it is because it
represents the very fragile state of technology - Supporting millions
of people, supported by 1 person.

New sites are also involved

Nano is an old project, but not only old projects are lonely, but new
ones also do, in the same way. But it's also, a different way. That
creates loneliness.

Technology only grabs attention when it can actually do something, or
when it is interesting, projects like Nginx and Chromium give a very
clear use, therefore people contribute to it and create an active
environment.

But not all provides this type of engagement and interest of
their websites and projects, take an example of my website at
vyang.org, this is a simple website about
myself.

I get about a few hundred unique visitors requesting my site; most of
them are robots or Internet scans for vulnerabilities. Almost 70% of my
requests are made by robots.

This gives you a fake feeling that your website is visited by a lot of
"people", but the "people" are not actual "people".

This impacted the creativeness of the Internet, as of most people are
moving into big platforms to post their things, and not like the
Internet before, where we have to go access the entire Internet to find
the solution to a problem.

Because of this, the Internet will be highly standardized, and now when
people try to do something, everything is the same.

Looking back, what we have now

I know that there are a lot of problems on the Internet, it is growing
fast, and it is very common that we will throw things away when we do
not need them anymore.

The issue is that when we throw away things, we do not stop depending on
it, while the attention is driven to new projects, the use of old ones
never stops, but the development slows or stops.

We constantly invent new things, and shift attention to them. But we
do not stop using them, causing a lot of old code to restrict the
development of new ones.

Until now, I want to reference a meme picture from the Cloudflare and
AWS outages, but the thin cylinder is the old software.

But the worse part about this is that when the fragile part is AWS or
Cloudflare, they have engineers waiting 24/7 to fix the problem, but for
old software, no one could fix it in time.

How do we solve it? Or do we need to solve it?

This is basically the entire post, what I want to say is that these all
happened because the Internet had developed too fast. That people did
not have time to absorb all the information and software already
created, and new ones had already been created..

What I think is that we should care about the old but software that you
use every day, you should always know that behind these software, there
are always 1 or few people working for it

The full more detailed version of this blog containing more of my opinions is available on vyang.org.

Building Bootable Images in Userspace: Avoiding the Loop Device Trap

Vincent Yang — Thu, 26 Mar 2026 00:00:00 +0000

Building Disk Images Without Root (And Without Regret)

If you have built enough disk images, you eventually hit the same Rite Of Passage:

It is 1:27 AM, you are tired, and you want run a fast "one-liner" with sudo dd or sudo mkfs.fat.
You falsely typed one character.
You did not wipe the test image.
You wipe a host partition.

That story is so common it might as well be onboarding material.

The trap is not triggered because low-level tools are bad. But because the trap is running low-level tools with maximum privilege on the host, in a workflow with high typo probability and weak guardrails.

This guide is about building bootable disk images in User Space while keeping Host Safety intact. And not get your host disk ruined.

Failure Mode: The Root Workflow Drift

Most people start with this pattern because it looks "standard":

# 1) Create a blank disk image
dd if=/dev/zero of=disk.img bs=1M count=512

# 2) Partition it
parted -s disk.img mklabel msdos mkpart primary fat32 1MiB 100%

# 3) Bind with a loop device
loop_dev=$(sudo losetup -fP --show disk.img)

# 4) Make filesystem + mount + copy
sudo mkfs.fat -F 32 "${loop_dev}p1"
mkdir -p ./mnt
sudo mount "${loop_dev}p1" ./mnt
sudo cp -r ./payload/. ./mnt/
sudo umount ./mnt
sudo losetup -d "${loop_dev}"

Nothing here is unusual. That is exactly why it is dangerous, because what you think is not dangerous could be very dangerous. This sequence normalizes a habit where every critical operation uses sudo, so one typo has host-level blast radius.

The Hierarchy of Hazard

Use a Symptom Vs Catastrophe model when evaluating root-heavy image workflows.

Tier 1: Annoying Symptom

Wrong partition offset in dd.
Files copied into the wrong path.
Disk not booting due to broken VBR.

These are fixable and mostly local to the image artifact.

Tier 2: Costly Symptom

Loop device leaks because losetup -d was skipped.
Confusing /dev/loopN state after repeated runs.
CI/CD scripts becoming non-deterministic.

Now your workflow degrades over time and debugging cost increases.

Tier 3: Catastrophe

mkfs points to a host partition instead of the image.
dd writes to the wrong block device.
grub-install targets host storage after device resolution fails.

At this tier, you are no longer "debugging an image." You are performing incident response on your own workstation.

What Usually Breaks First

Loopback Device Lifecycle

What Breaks

Loop devices accumulate when scripts exit early or cleanup paths are missed. Eventually your flow depends on stale /dev/loopN state and implicit assumptions about which loop index maps to which file.

Why it Matters

Your build stops being deterministic. On a good day it "works on my machine". On a bad day it formats the wrong target because loop_dev is not what your script thinks it is.

GRUB Target Resolution

What Breaks

grub-install is called with an invalid or unexpected target device, then falls back to behavior you did not intend, GRUB will fallback to your host disk if the disk you specified to GRUB does not exist.

Why it Matters

Bootloader writes are destructive by design. A mis-targeted install can modify host boot configuration and convert a test run into a host recovery task.

Three User Space Strategies

The goal is simple: no mount(2), no host loop device dependency for routine file operations, and minimal root privilege.

Option 1: Libguestfs (`guestfish`)

guestfish builds and edits disk images inside an appliance VM. That isolation is the key safety property.

guestfish << 'EOF'
sparse disk.img 512M
run
part-init /dev/sda mbr
part-add /dev/sda p 2048 -1
mkfs vfat /dev/sda1
mount /dev/sda1 /
copy-in payload/. /
sync
quit
EOF

Pros

Strong Host Safety boundary because operations happen in a guest appliance.
Scriptable for CI with stable command primitives.
Good default for "just make me a bootable image" pipelines.

Cons

Slower on weak hosts because all I/O is VM-mediated.
Kernel/appliance setup can be brittle on some distros.
FAT behavior can become MysteryMeat in edge sizes.

On that FAT point: mkfs vfat may auto-select FAT12/FAT16/FAT32 based on partition geometry. You can end up with a FAT16-style VBR while the partition type marker says 0x0c (FAT32 LBA). The image is technically "built," but tooling assumptions diverge and boot behavior becomes inconsistent, if you have your own OS, it may be a problem.

When to use this

Use when you want maximum safety and can tolerate lower build speed, it is also good when you want maximum customizability.

Option 2: DiskCombining (Assemble Image Segments)

This method creates partition payloads separately, then injects them into a pre-partitioned disk image. It favors explicit geometry control and reproducibility.

disk_size_mb=512
part_size_mb=511
part_start_lba=2048

dd if=/dev/zero of=disk.img bs=1M count="${disk_size_mb}"

# Create partition table non-interactively
parted -s disk.img mklabel msdos
parted -s disk.img mkpart primary fat32 1MiB 100%

# Build partition payload independently
dd if=/dev/zero of=part.img bs=1M count="${part_size_mb}"
mkfs.fat -F 32 part.img

# Populate partition payload using user-space FAT tools
mmd -i part.img ::/boot
mcopy -i part.img kernel.bin ::/boot/kernel.bin

# Inject partition payload at the partition start
dd if=part.img of=disk.img bs=512 seek="${part_start_lba}" conv=notrunc

# Set partition type to W95 FAT32 (LBA)
printf '\x0c' | dd of=disk.img bs=1 seek=450 conv=notrunc

Pros

Maximum control over geometry, offsets, and byte-level layout.
Fast and deterministic once script variables are correct.
Works well for advanced boot experiments.

Cons

Higher cognitive load; offset math mistakes are easy.
MBR-first workflows are simpler here than GPT-first workflows.
You own all correctness checks.

When to use this

Use when you need precise layout control and are comfortable validating disk geometry manually.

Option 3: mtools-First FAT Workflow

This is the most underrated path for FAT boot media. Use mtools to manipulate filesystems entirely in UserSpace.

# Create FAT image file directly
dd if=/dev/zero of=part.img bs=1M count=64
mkfs.fat -F 32 part.img

# No mount syscall required
mmd -i part.img ::/EFI
mmd -i part.img ::/EFI/BOOT
mcopy -i part.img BOOTX64.EFI ::/EFI/BOOT/BOOTX64.EFI

Pros

mcopy and mmd operate without mount, so no root requirement for file operations.
Cleaner CI scripting because there is no loop device lifecycle to manage.
Excellent for FAT payload staging before final disk assembly.

Cons

Primarily useful for FAT workflows; not a universal filesystem toolkit.
Less familiar to developers used to mount + cp habits.
You still need a partitioning plan for full-disk images.

When to use this

Use when your target is FAT-based boot media and you want the safest day-to-day developer loop.

Practical Verdict

If you optimize for Safety First: choose guestfish.
If you optimize for Layout Control: choose Disk Combining.
If you optimize for daily velocity on FAT images: choose mtools + assembly.

My default in real projects is hybrid:

Use mtools for payload edits.
Use Disk Combining for reproducible final image assembly.
Keep guestfish as the "safe fallback" when environment-specific tools become noisy.

This keeps the core loop in UserSpace while preserving deep control when needed.

Conclusion

Root privileges are not a badge of low-level skill. They are a liability multiplier.

If your disk workflow requires frequent sudo, you are one typo away from turning a build task into a recovery task. Shift routine image operations to UserSpace, isolate risky steps, and reserve privilege for the rare places where it is truly necessary.

Experiments & Resources

I spend roughly 6 hours a week outside my main work researching these systems performance bottlenecks and refining my build toolchain. For those building for unpackage, I’ve packaged my advanced, rootless disk-building scripts—along with the full source for this experiment into the latest code bundle on my Support page. It’s the fastest way to move from this theory to a repeatable production pipeline.

Setup OSDev Environment on macOS

Vincent Yang — Thu, 19 Mar 2026 00:00:00 +0000

Why OSDev on macOS works (if you stop fighting defaults)

The failure mode is always the same: you follow an OSDev tutorial, hit make, and end up with a binary that either won’t boot, won’t link, or isn’t even in the format your bootloader expects.

macOS is a great editor and workflow environment. But it is a terrible default build target for classic OSDev.

This guide builds a layered mental model for the “why”, then gives three setups (from lightest to heaviest) that I’ve used successfully: a cross-toolchain on macOS, a Docker build container, and a Linux VM via Lima.

The two hard constraints (the stack you can’t ignore)

1) CPU architecture: aarch64 vs x86

Modern Macs (M1/M2/M3/M4) are aarch64 (ARM64) machines. Most OSDev examples, bootloaders, and “hello kernel” walkthroughs targets i686/x86_64.

What breaks: Native clang/ld produce ARM machine code by default.
Why it matters: An x86 emulator (or real x86 hardware) can’t execute ARM opcodes. If your kernel is the wrong ISA, you won’t get “a little wrong” behavior—you’ll get a hard stop.

If you are targeting ARM on purpose, you still have the second constraint.

2) Executable format: Mach-O vs ELF

macOS uses Mach-O. Most OSDev toolchains and boot flows assume ELF.

ELF: The common format for Linux/BSD tooling and OSDev build systems.
Mach-O: The native macOS format, tightly integrated with Apple’s linker/loader and platform conventions.
What breaks: Bootloaders, kernels, and link scripts in OSDev projects often expect ELF sections/symbol layout and ELF headers.
Nuclear option (don’t do this): Write your own linker (or a Mach-O loader in your boot path) just to make the native toolchain fit.

Three working setups (from native → isolated → maximum compatibility)

Option 1: Cross-compiler on macOS (fastest feedback loop)

This is the “keep everything local” setup:

Editor: macOS
Build toolchain: i686-elf-* or x86_64-elf-*
Output: ELF binaries for your target

Path A: Homebrew (the quick start)

If all you need is a usable cross toolchain, Homebrew is the shortest path.

brew install i686-elf-binutils i686-elf-gcc

Pros: Minutes to set up.
Cons: Less control. Once you start building a libc, switching freestanding/hosted modes, or pinning specific versions, you’ll want a source build.

Path B: Build from source (the “I want it correct” path)

This is the common OSDev approach: build binutils first, then build GCC against it.

Why this order matters

Binutils provides as (assembler), ld (linker), and friends.
GCC will call into those tools when producing final objects/binaries.

Binutils example (i686-elf)

# Native compiler toolchain for building tools
xcode-select --install

# Fetch sources
wget https://ftp.gnu.org/gnu/binutils/binutils-2.45.tar.gz
tar -xvf binutils-2.45.tar.gz

# Out-of-tree build keeps your source directory clean
mkdir -p binutils-2.45/build
cd binutils-2.45/build

# Key flags:
# --target=i686-elf    => produce tools that emit i686 code and ELF output
# --prefix=...         => install into an isolated directory
# --disable-nls        => disables Native Language Support (fewer deps, faster build)
# --disable-werror     => warnings won't fail the build on strict compilers
../configure \
  --target=i686-elf \
  --prefix=/usr/local/cross \
  --disable-nls \
  --disable-werror

# macOS doesn't ship `nproc` by default
make -j"$(sysctl -n hw.ncpu)"
make install

Repeat the same pattern for GCC, pointing it at the same --target and --prefix.

Option 2: Docker (portable + reproducible)

Docker gives you a clean Linux build environment while keeping your source on the host.

What you gain: A pinned, shareable toolchain across machines.
What you lose: Some performance (especially if you force x86 emulation on Apple Silicon).

Minimal Dockerfile skeleton

FROM --platform=linux/amd64 ubuntu:latest

RUN apt-get update && apt-get install -y \
    build-essential \
    wget \
    nasm \
    qemu-system-x86

# Toolchain install/build goes here:
# - install prebuilt x86_64-elf toolchain packages, OR
# - build binutils+gcc from source inside the image

WORKDIR /osdev
CMD ["/bin/bash"]

Build + run

docker build -t osdev-env .

# -v maps your current folder into the container
docker run --rm -it -v "$(pwd)":/osdev osdev-env make

Why --platform=linux/amd64 matters
On Apple Silicon, this forces an x86_64 userland. That can increase compatibility with prebuilt toolchains, but it may run slower due to emulation.

Option 3: Linux VM via Lima (maximum compatibility)

If you want the least “mystery meat” behavior, stop fighting macOS and build inside Linux.

This is the nuclear option for compatibility: it matches the environment most OSDev docs assume.
Workflow: edit on macOS, build/run in Linux, attach VS Code via SSH.

Install Lima

brew install lima

Create and enter a VM

limactl start --name osdev template://ubuntu
limactl shell osdev

Mount your source directory (host ↔ guest)

Edit the instance config:

limactl edit osdev

Add a writable mount:

mounts:
  - location: /path/to/your/os/source/code
    writable: true

VS Code integration

Add to your SSH config so your editor can see Lima hosts:

Include ~/.lima/*/ssh.config

Editor UI: macOS
Build tools + QEMU: inside the VM

Run QEMU inside the VM

sudo apt-get update
sudo apt-get install -y qemu-system-x86

# Example: adjust to your boot flow / image layout
qemu-system-x86_64 -m 512M -net none -kernel /path/to/your/os/kernel

Conclusion

Pick the lightest setup that gives you deterministic results:

Cross-compiler: Best day-to-day speed on macOS.
Docker: Best reproducibility for teams and CI.
Lima VM: Best compatibility when you’re deep in toolchain/bootloader land.

If you want a full Linux host on Apple Silicon without virtualization, Asahi Linux is the endgame.

Experiments & Resources

To keep this post focused on the core concepts, I’ve hosted the full code bundles, and early-access development logs on my personal site. If you're looking to run these you can find everything here:

View Project Files & Early Access

Website Deployed but Nothing Changed

Vincent Yang — Sat, 14 Mar 2026 02:08:00 +0000

Introduction

If you have built a website, you have likely encountered the specific frustration of deploying to the global network: you update a CSS style or patch a JavaScript bug, but the production site stubbornly serves the old version. Only your users see the "broken" state. This is especially painful during emergency hotfixes or when debugging environment-specific issues on platforms like PHP.

I personally lost hours debugging this exact blog, simple PHP and CSS because of stale code. What takes 1 hour on localhost can take 5 in production. On localhost, the loop is tight. On the open web, you are fighting against multiple layers of optimization designed to prevent exactly what you are trying to do. Which is download fresh files.

The Stack Trace of Caching

If your site isn't updating, work through the failure points in this order, from "User Error" to "Architecture".

1. Failed to Deploy

Before blaming the network, blame the pipeline. Despite the title "deployed but nothing changed", there is a non-zero chance you haven't actually deployed.

Did the GitHub Action runner actually turn green? Did the rsync script fail silently due to permissions or clock skew?
Always verify the file modification time on the server first. ls -l can help you check the file time. If the file is old on the disk, no amount of cache purging will fix the client.

2. Caching Layers

The most common culprit is caching. It's not a single entity; it is a stack. You have Server caching (PHP OpCode), Load Balancers, DNS, CDNs, ISP transparent proxies, and finally, the user's browser. Even one stale layer breaks the chain.

Layer 1: The Browser Cache

Browsers aggressively cache static assets (CSS, JS, Images) to save battery and data.
For Local Debugging:

Hard Reload: Force the browser to bypass its cache. Ctrl + Shift + R (Windows/Linux) or Command + Shift + R (macOS).
DevTools: Open the Network tab in your browser's developer tools and check "Disable cache". As long as that pane is open, you will get fresh files.

For Production (The Configuration Fix):
To ensure all clients see changes immediately, you must instruct the browser not to trust its local copy. You do this with the Cache-Control HTTP header. The directive no-cache, no-store, must-revalidate is the nuclear option for ensuring freshness.

Nginx Configuration:
Add this to your server or location block for your static assets:

location ~* \.(css|js|png)$ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
}

Apache Configuration (.htaccess):
Ensure mod_headers is enabled and add this:

<FilesMatch "\.(css|js|png)$">
    <IfModule mod_headers.c>
        Header set Cache-Control "no-cache, no-store, must-revalidate"
    </IfModule>
</FilesMatch>

Note: This forces every client to hit your server for every asset, maximizing freshness but increasing server load.

Layer 2: Network & Edge Caches (CDNs)

If you use a CDN (like Cloudflare, AWS CloudFront, or Fastly), setting headers on your origin server isn't enough if the CDN has already cached the old file. The Cache-Control header will eventually propagate, but for immediate fixes, you must Purge the cache.

Action: Log into your CDN dashboard and look for "Purge Cache" or "Invalidate". You can usually purge a specific URL (lighter) or the entire zone (nuclear).
Strategy: Don't rely on manual purges. Configure your CDN to respect your Cache-Control headers, or better yet, use Versioning (see below).

Layer 3: Server-Side Caching (OpCode)

For interpreted languages like PHP, the server often caches the compiled bytecode (OpCode) in memory to avoid parsing the script on every request.

The Symptom: You updated index.php, the file on disk is new, but the server returns the old logic.
The Fix: You may need to restart your PHP service (service php-fpm restart) or tune your opcache.revalidate_freq setting in php.ini to check for file changes more frequently.

The Ultimate Fix: Versioning (Cache Busting)

Purging caches and wrestling with headers is reactive. The industry-standard solution is Versioning (or Cache Busting).

Browsers identify files by URL.

style.css = Browser checks cache.
style.v2.css = Browser treats it as a new resource.

You don't need to manually rename files. Since you are using PHP, automate it by appending the file's Modification Time as a query parameter.

The PHP Auto-Versioning Strategy:
Instead of a static link:

<link rel="stylesheet" href="style.css">

Inject the file's timestamp dynamically:

<link rel="stylesheet" href="style.css?v=<?php echo filemtime('style.css'); ?>">

How this solves everything:

filemtime reads the Unix timestamp of the last save (e.g., 1678123456).
The rendered HTML is <link href="style.css?v=1678123456">.
As long as you don't touch the file, the URL stays the same (Cache Hit).
The second you deploy a change, the timestamp updates, the URL changes, and every browser, CDN, and proxy is forced to fetch the new version instantly.

Conclusion

Debugging deployment issues is about eliminating variables.

Verify the file is actually updated on the server disk.
Bypass your local cache (DevTools).
Control downstream caching with Cache-Control headers (Nginx/Apache).
Automate freshness with Cache Busting version strings.

DEV Community: Vincent Yang

The Internet is a Thin Cylinder: Supporting Millions, Supported by One

Why is this an actual thing?

An example of this

New sites are also involved

Looking back, what we have now

How do we solve it? Or do we need to solve it?

Building Bootable Images in Userspace: Avoiding the Loop Device Trap

Building Disk Images Without Root (And Without Regret)

Failure Mode: The Root Workflow Drift

The Hierarchy of Hazard

Tier 1: Annoying Symptom

Tier 2: Costly Symptom

Tier 3: Catastrophe

What Usually Breaks First

Loopback Device Lifecycle

What Breaks

Why it Matters

GRUB Target Resolution

What Breaks

Why it Matters

Three User Space Strategies

Option 1: Libguestfs (guestfish)

Pros

Cons

When to use this

Option 2: DiskCombining (Assemble Image Segments)

Pros

Cons

When to use this

Option 3: mtools-First FAT Workflow

Pros

Cons

When to use this

Practical Verdict

Conclusion

Experiments & Resources

Setup OSDev Environment on macOS

Why OSDev on macOS works (if you stop fighting defaults)

The two hard constraints (the stack you can’t ignore)

1) CPU architecture: aarch64 vs x86

2) Executable format: Mach-O vs ELF

Three working setups (from native → isolated → maximum compatibility)

Option 1: Cross-compiler on macOS (fastest feedback loop)

Path A: Homebrew (the quick start)

Path B: Build from source (the “I want it correct” path)

Option 2: Docker (portable + reproducible)

Minimal Dockerfile skeleton

Build + run

Option 3: Linux VM via Lima (maximum compatibility)

Install Lima

Create and enter a VM

Mount your source directory (host ↔ guest)

VS Code integration

Run QEMU inside the VM

Conclusion

Experiments & Resources

Website Deployed but Nothing Changed

Introduction

The Stack Trace of Caching

1. Failed to Deploy

2. Caching Layers

Layer 1: The Browser Cache

Layer 2: Network & Edge Caches (CDNs)

Layer 3: Server-Side Caching (OpCode)

The Ultimate Fix: Versioning (Cache Busting)

Conclusion

Option 1: Libguestfs (`guestfish`)