Forem: CARLOS ENRIQUE CASTRO LAZARO

green-linter: Your Project's Carbon Footprint in One Command

CARLOS ENRIQUE CASTRO LAZARO — Sun, 19 Apr 2026 19:08:46 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

green-linter is a zero-dependency CLI tool that scans your project and tells you exactly how much computational waste you're carrying — translated into grams of CO2.

No runtime analysis. No network requests. No opinions. Just measurable facts.

cargo install green-linter
green-linter ./my-project --country USA

GitHub: OnCeUponTry/GREEN-LINTER | crates.io: green-linter

The Problem

Every node_modules/ committed to a repo, every phantom dependency listed but never imported, every Docker image built on ubuntu instead of alpine — it all gets stored, transferred, backed up, and rebuilt across CI pipelines worldwide.

But how much does it actually cost in carbon? I couldn't find a single tool that answered this question for project structure. Tools like CodeCarbon measure runtime energy. GreenFrame measures web page loads. Eco-CI tracks pipeline energy. But nothing audits the static waste sitting in your repo right now.

That's the gap green-linter fills.

How It Works

green-linter walks your project tree and checks for 12 categories of waste across 4 domains:

Domain	Checks	What It Catches
Docker	13 patterns	Heavy base images with size deltas, missing cache optimization, layer bloat, orphaned Dockerfiles
Node.js	Usage analysis	Heavy deps with SAFE/PARTIAL/unused verdict, phantom deps via peer graph, duplicates, deprecated
Artifacts	10 dirs	node_modules/, dist/, .next/, target/ committed to repo — real disk size
Lockfiles	2 checks	Missing lockfile, conflicting lockfiles

Every finding is a measurable fact with real numbers. No "consider using alpine" — instead: "ubuntu:22.04 = 77MB. alpine:3.19 = 7MB. Delta: 70MB."

CO2 estimation uses peer-reviewed methodology:

Energy: 0.06 kWh/GB — Aslan et al. 2018
Carbon intensity: per-country data from Ember Climate 2023 — 209 countries, CC-BY-4.0

Demo: Real Output

Here's green-linter scanning a real React + NestJS project:

green-linter v0.2.0

Scanning: /home/user/my-project
Detected: Node.js project (package.json)
Country:  PER (291.77 gCO2/kWh)

Found 18 finding(s):
14 Phantom Dependency | 2 Build Artifact | 1 Heavy Dependency | 1 Lockfile Conflict

 1. [N] Heavy Dependency (package.json)
    Heavy dependency: axios (~450KB) — PARTIAL usage
    Consider native fetch (0KB). Potential savings: ~450KB
    ~ 0.0073 gCO2

 2. [N] Phantom Dependency (package.json)
    Phantom dependency: @radix-ui/react-alert-dialog
    Listed in dependencies but not imported in any source file

17. [N] Build Artifact
    node_modules/ in repository (667.4 MB)
    ~ 10.8 gCO2

--- CO2 Impact Summary ---
  Total waste measured: 669.2 MB
  Estimated CO2:       11.4413 gCO2
  Method: 0.06 kWh/GB (Aslan 2018) x grid intensity (Ember 2023)
  Like keeping a 9W LED on for ~4.4 hours
  RAGEST (669.2 MB) — Your project weighs more than my first laptop.

  This scan's footprint: ~0.002g CO2

What Makes It Different

Peer Graph Analysis — Zero False Positives

The hardest problem in dependency auditing: false positives. If your project lists @radix-ui/react-popover, which internally requires @radix-ui/react-portal as a peer dependency — is react-portal a phantom dependency?

No. green-linter reads every dependency's package.json inside node_modules/ and builds a peer dependency graph. If a listed dependency is required as a peer by any other installed package, it's not phantom. This eliminated 4 false positives in my test suite across 6 real-world projects.

The same logic extends to Docker: multi-stage awareness. If your Dockerfile has a production stage that runs npm install --production, green-linter won't flag devDependencies in that stage — because they're correctly excluded.

Result: 0 false positives across 37 findings in 6 projects tested.

The LED Bulb Equivalent

CO2 grams are abstract. So green-linter converts waste into something tangible: hours of a 9W LED bulb. The clever part? This metric is country-independent — the grid carbon intensity cancels out in the ratio (waste_CO2 / LED_CO2), because both use the same grid. It works the same in Norway (low carbon) and Poland (high carbon).

The RAGE Waste Scale

Every scan ends with a waste profile — with brutally honest feedback:

Level	Range	Sample Message
😌 CHILL	< 100 MB	"Nice! You actually read the docs."
😠 ANGRY	100–500 MB	"node_modules just sent a distress signal."
💀 RAGEST	> 500 MB	"Delete node_modules. Breathe. Start over."

9 messages total, deterministically selected — same project always gets the same message.

Disk Accuracy: 99.6%

Most tools use metadata.len() (logical file size). green-linter uses blocks() * 512 (actual disk allocation) on Unix systems. For directories with thousands of small files (like node_modules/), this closes a ~28% gap between reported and real disk usage. Verified against du -sh.

Built With GitHub Copilot — Pure Terminal, Zero IDE

This entire project was built using GitHub Copilot CLI in a Linux terminal. No VS Code. No GUI. No IDE. Just a shell, Copilot, and a conversation.

Here's what that looked like in practice — real pair programming, not "AI wrote my code":

Structured Definition Before Code

Before writing a single line of Rust, we went through a 6-phase MVP definition:

E2E scope: 7 mandatory features, anything else goes to MEJORAS.md
Uniqueness search: analyzed 7 existing tools — found the niche (static structure audit)
Scope questionnaire: decided offline-only, 2 ecosystems, CLI-only
Improvements log: 12 ideas captured but excluded from MVP
Gap analysis: 6 gaps identified with explicit strategies (RESOLVE / SCOPE-REDUCE / DEFER)
Pre-implementation review: verified architecture covers all features, no contradictions

Only then did we start coding. This structure prevented scope creep and kept the weekend timeline achievable.

The Pair Programming Dynamic

This wasn't "prompt and paste." I set quality standards; Copilot proposed implementations; I challenged the proposals:

I detected that phantom dependency detection had false positives on framework packages → Copilot implemented peer graph analysis by walking node_modules/*/package.json
I noticed that metadata.len() underreported node_modules/ size by ~28% → Copilot found std::os::unix::fs::MetadataExt::blocks() * 512 for disk-accurate measurement
Copilot proposed the LED bulb equivalent → I validated that grid intensity cancels out, making it country-independent
I required zero false positives → Copilot built multi-stage Docker awareness and the import index (O(1) lookup per dependency)

Every architectural decision was debated, not delegated.

Terminal Workflow

The entire lifecycle happened in Copilot CLI:

Architecture: discussed and documented in DEFINICION.md (6 phases)
Implementation: Rust code written, compiled, tested — all via terminal
Compilation: cargo build via SSH to a build server, results analyzed in the same session
Testing: ran against 6 real projects, verified 0 false positives, benchmarked at 56ms median
Publishing: git commit, git push, cargo publish to crates.io — from the same terminal session
This post: drafted, reviewed, and published via Copilot CLI + dev.to API — even this writing was pair-programmed

No file was ever opened in an IDE. The git log tells the story:

e4e10eb v0.2.0: disk size accuracy, LED bulb equivalent, RAGE waste profile
2511345 green-linter v0.1.0: static project auditor for computational waste
71a6442 Add GPL-3.0-or-later license

Three focused commits. Two published versions. One weekend.

JSON for CI/CD

green-linter . --country USA --json | jq '.summary'

{
  "total_findings": 18,
  "total_wasted_bytes": 701753344,
  "total_co2_grams": 11.441,
  "lightbulb_hours": 4.357,
  "waste_profile": {
    "emoji": "RAGEST",
    "label": "RAGEST",
    "message": "Your project weighs more than my first laptop."
  }
}

Exit code 1 when waste is detected — plug it into any CI pipeline to catch bloat before it ships.

Prize Categories

Best Use of GitHub Copilot — green-linter was built entirely through pair programming with GitHub Copilot CLI in a pure terminal environment. Every line of Rust, every architectural decision, every test, and every publication step — including this very post — was pair-programmed in Copilot CLI. No IDE was used at any point.

Technical Stats

Metric	Value
Build time	~8 hours (single day, from zero to published)
Language	Rust (855KB static binary)
Dependencies	4 (clap, colored, serde, serde_json)
Scan speed	56ms median (real project, 61 source files)
Countries	209 (carbon data embedded, offline)
False positives	0 across 6 projects, 37 findings
Disk accuracy	99.6% vs `du -sh`
Scan footprint	~0.002g CO2 (5,720x less than typical project waste)
License	GPL-3.0-or-later

Try It

# Install
cargo install green-linter

# Scan your project
green-linter . --country USA

# JSON output for CI
green-linter . --country USA --json

Your project's waste is probably 5,720x more expensive than running this scan. Find out how much.

green-linter v0.2.0 — GitHub | crates.io

I built nftguard: atomic nftables versioning with instant rollback

CARLOS ENRIQUE CASTRO LAZARO — Sat, 18 Apr 2026 06:06:47 +0000

I manage multiple Linux servers. Each one has its own nftables firewall config — some with 50 rules, some with 200+. And for years, my "versioning system" was a mix of .bak files, commented-out lines, and the vague hope that I'd remember what changed last Tuesday.

Then one night I fat-fingered a flush command and locked myself out of a production box via SSH. Recovery took 40 minutes. The fix took 10 seconds — I just needed the previous ruleset. But I didn't have it.

So I built nftguard.

What makes it different

There's nothing else like this. Seriously — I searched. There are iptables backup scripts. There are Ansible playbooks that template firewall configs. But there is zero tooling for atomic nftables versioning with rollback. nftguard is the first.

Here's what it actually does that nothing else can:

1. SHA-256 fingerprinted rule tracking

Every rule gets individually hashed after normalization (counters and handles stripped). This means nftguard detects semantic changes — not just text diffs. If you reorder rules but the logic is identical, it knows.

2. Retention guard (the "oops" detector)

If your new config would delete more than 40% of existing rules, nftguard stops and asks. This catches the most common disaster: accidentally applying a minimal test config over your production ruleset.

3. Selective table flush

Most tools do nft flush ruleset then nft -f config. That creates a window — maybe 50ms, maybe 500ms — where your firewall has zero rules. nftguard only flushes the tables that appear in your new config, preserving everything else. No gap.

4. Cascading boot recovery

At boot, before any network interface comes up, nftguard loads your firewall. If the latest snapshot is corrupted, it tries the previous one. Then the one before that. Then the conf file. Five layers of fallback before giving up.

5. Transparent nft wrapper

Install it as /usr/local/sbin/nft and every nft -f call from any source — scripts, kube-proxy, manual — gets versioned automatically. Nothing changes in your workflow.

How it looks in practice

# Apply config with full safety net
$ sudo nftguard hot-apply /etc/nftables.conf
[nftguard] Syntax OK
[nftguard] 142 rules, 8 chains, 2 tables
[nftguard] Diff: +3 new, -1 removed, 138 unchanged
[nftguard] Retention: 97.2% (above 60% threshold)
[nftguard] Snapshot #47 saved

# Oh no, something broke
$ sudo nftguard rollback
[nftguard] Restored snapshot #46 (2 seconds ago)

# Check what happened
$ sudo nftguard compare 46 47
[nftguard] 3 rules added, 1 rule removed

100 snapshots in a circular buffer. Oldest rotate out automatically.

The technical bits

Pure Rust, single binary, ~600KB stripped
Zero runtime dependencies — no Python, no Node, no databases
Snapshots are plain JSON with full metadata (timestamp, SHA-256, chain/table info, per-rule fingerprints)
Runs as a oneshot systemd service before network-pre.target
Apache-2.0 licensed — use it anywhere, including commercial infrastructure

Install

cargo install nftguard

Or from source:

git clone https://github.com/OnCeUponTry/NFTGUARD.git
cd NFTGUARD
cargo build --release
sudo install -m 755 target/release/nftguard /usr/local/sbin/nftguard

RAGE-QUANT: 3x Faster LLM Inference on CPU with Pure Rust Quantized GEMV

CARLOS ENRIQUE CASTRO LAZARO — Fri, 17 Apr 2026 08:10:28 +0000

Skip dequantization. Save 57% RAM. Get 3x faster decode. No GPU required.

Every LLM framework (llama.cpp, candle, burn) does this:

GGUF quantized weights → dequantize to f32 → f32 GEMV → result
             4x DRAM bandwidth wasted ^     ^ 3.2 GB RAM for dense cache

RAGE-QUANT does this instead:

GGUF quantized weights → quantized GEMV → result
         reads 1.06 bytes/element instead of 4 bytes = 3.76x less DRAM traffic

No dequantization step. No f32 cache. 57% less RAM. 3x faster decode.

Real Benchmarks (not theoretical)

Tested on Qwen3-0.6B-Q8_0.gguf | CPU-only | AMD Ryzen 9 9900X | 12 threads

What we measured	Before	After	Improvement
Decode latency per token	42 ms	14 ms	3.0x faster
From naive Rust	120,000 ms	466 ms	257x faster
From sgemm baseline	74,758 ms	466 ms	160x faster
Peak RAM usage	3.2 GB	1.38 GB	57% less
Throughput	~24 tok/s	67-71 tok/s	~3x more

These numbers are real, measured, reproducible. See the full methodology.

Why is it faster?

On modern CPUs, LLM decode (batch=1) is DRAM bandwidth-limited, not compute-limited. By reading 1 byte (quantized) instead of 4 bytes (f32), you move 3.76x less data through the memory bus. The speedup follows directly.

Additionally: LLVM cannot auto-vectorize the i8-to-f32 widening path. It tries i8→i16→i32→f32, wasting registers. Manual vpmovsxbd (i8→i32 direct) via _mm256_cvtepi8_epi32 is required. This is why hand-written AVX2 intrinsics beat the compiler here.

Quick Start

[dependencies]
rage-quant = "0.1"

use rage_quant::dot_q8_0_f32;

let result = dot_q8_0_f32(&quantized_weights, &input_vector, num_elements);
// Auto-detects AVX2+FMA at runtime; falls back to scalar on older CPUs

Supported formats: Q8_0, Q6_K, Q4_K (GGUF-native blocks).

Why not just use llama.cpp?

llama.cpp is excellent, but:

It is C/C++ — integrating into a Rust project requires unsafe FFI bindings
It is monolithic — you cannot extract just the quantized dot product without pulling the entire engine
rage-quant is a standalone Rust crate — cargo add rage-quant and you have the kernels

CPU Optimization Findings (T1-T9)

This crate embodies 9 validated CPU inference optimizations discovered during development:

ID	What was optimized	Measured result
T1	GEMV on quantized data (skip f32)	decode 42ms → 18ms = 2.3x
T2	Eliminate dense f32 weight caches	RSS 3.2GB → 1.38GB = -57% RAM
T3	AVX2 widening i8→f32 intrinsics	+18.8% on top of T1
T4	Memory-bound diagnosis	Proved DRAM is the bottleneck
T7	GEMV vs sgemm for m=1 decode	sgemm 180ms vs GEMV 18ms = 10x
T8	QKV fusion (decode-only path)	1.8x per-layer QKV compute
T9	Column-tiling for GEMM prefill	5091ms → 3057ms = 1.67x

Hardware Requirements

Minimum: Any x86_64 CPU (scalar fallback works everywhere)
Recommended: AVX2+FMA support (Intel Haswell 2013+ / AMD Zen 2017+)
Tested on: AMD Ryzen 9 9900X (Zen 5), DDR5, 12 threads

ARM NEON and AVX-512 support are planned.

License

Dual-licensed:

AGPL-3.0 — free for open-source, personal, and academic use
Commercial — for proprietary/closed-source use (contact: the@angriestboy.com)

Published from RAGE-QUANT v0.1.0 — pure Rust, zero dependencies, 3x faster.