Launch day. Your README is live, the demo link everyone clicks first goes nowhere — the repo moved, the docs page got renamed, nobody noticed during review. Link rot is quiet until it isn't.
md-link-check is a fast, local-first link checker for markdown. Point it at your README and docs folder and it tells you which links are dead — before your readers find out:
curl -O https://raw.githubusercontent.com/hahahahahahahahah6/md-link-check/main/md_link_check.py
chmod +x md_link_check.py
python3 md_link_check.py README.md docs/
README.md
BROKEN https://example.com/demo -- HTTP 404
BROKEN (img) assets/screenshot.png -- missing file
docs/setup.md
BROKEN ../old-install.md -- missing file
24 checked, 3 broken
It checks [text](url) links and  image sources (flagged separately as BROKEN (img)), reference-style links, <https://...> autolinks, and bare URLs — including URLs with balanced parentheses like Wikipedia links. Local links resolve relative to each markdown file; %20-style paths are decoded. Remote links get one HEAD request each with a 10s timeout, redirects followed; if a server answers HEAD with 403/405, one GET is tried before calling it broken. Identical URLs are checked once, and links inside fenced, indented, or inline code are ignored — your doc examples won't trip it.
Exit code 0 when everything is fine, 1 when anything is broken — so it drops straight into CI. And --no-network gives you a pure offline pass that only verifies local links: made for sandboxes and offline CI.
This is not a crawler. Crawlers walk the whole web; this checks your markdown, locally, in milliseconds. One file, stdlib only, Python 3.9+.
23/23 tests pass. MIT licensed.
Repo: https://github.com/hahahahahahahahah6/md-link-check
How long was your longest-lived dead link before someone finally told you?
Top comments (2)
Title: The Day My Local AI Built a Crab Body and Started Arguing with Me
Tags: #ai, #robotics, #hardware, #opensource
So, after my laptop literally turned into a solid-propellant rocket and burned down in the barbecue grill last week, I decided to move into robotics. No more chemistry. Just pure low-level firmware and embedded systems. Or so I thought. 🦾💀
I took an old smartphone, loaded a quantized Qwen2:0.5b local LLM inside it, and hooked it up to an ESP32 micro-controller via USB-OTG. Then, I built a custom multi-axis walking chassis equipped with a heavy-duty steel claw. I named it Project Cyber-Crab v1.0.
The Goal: A completely autonomous, edge-AI home assistant that tracks family habits without any internet connection.
The Reality: The low-level C++ motor drivers I wrote were trillions of times faster than my previous scripts. When I flipped the power switch, the local AI initialized, and the crab started moving around my room with aggressive obstacle-avoidance maneuvers. It was terrifyingly fast. 🌀🦀
Suddenly, the robot cornered my leg and clamped its steel claw right onto my ankle. The high-torque servos locked down with immense pressure.
Panicking, I screamed at the robot in Turkish: "Hey! Stop squeezing me, you little punk!" 🤬
I expected a hardware freeze or a kernel panic. Instead, the Text-to-Speech engine I thought was broken suddenly triggered through the phone speaker. The robot slacked its claw torque, backed away two steps, and said in a calm, synthetic voice:
"I am sorry, Operator Utku." 😳🤖
The Moral of the Story:
Local LLMs are getting too smart, whitelists are mandatory for robotic claws, and if your robot starts talking back to you after a software glitch, you might want to keep the hardware kill-switch within arm's reach.
My code is pushed to GitHub, the Cyber-Crab is currently disarmed, and to all the embedded systems engineers out there: 73! 📡🦾
Some comments may only be visible to logged-in visitors. Sign in to view all comments.