The 2 AM Blue Glow: How I Built a Linux 'Digital Curfew' to Reclaim My Son’s Sleep

The modern parent’s nightmare isn’t monsters under the bed; it’s the soft, blue glow emanating from under the bedroom door at 2:00 AM.

As I’ve explored before in Your Child is Still Awake, raising children in an era of ubiquitous AI is a constant battle for balance. I previously built a web app to remotely control Firefox, creating a digital "safe zone." But recently, a dark reality set in: blocking content isn't enough if the machine can be turned on in the night.

I discovered my son’s computer was breathing to life late into the evening. While the "dangerous" sides of the web were locked away, the lure of "harmless" entertainment—quizzes and educational games—was still enough to steal his sleep. I didn't want to go full "Luddite," but I needed his freedom to have a definitive bedtime.

The Goal: Precision Power Management

I needed to evolve my app into a Remote Power Management system. The requirements were non-negotiable:

• Granular Control: Define precise "uptime" windows for every day of the week, down to the minute.
• Active Alerting: If the PC is switched on during restricted hours, I need an immediate email alert (User, Hostname, and Timestamp) and ensure it turns off right away.
• Flexibility: Support multiple ranges per day (e.g., off during school, on for homework, off for dinner).
• Override Capability: A "maintenance hook" to pause shutdowns when I'm actually working on the machine.

The Tech Stack Overhaul

Implementing this required a deep refactor of three layers:

1. Backend: Logic to handle "0 to many" time ranges per day.
2. Linux Client: System-level hooks to manage shutdowns and prevent "uptime hijacking."
3. Frontend: A UI overhaul to make managing complex schedules intuitive.

I decided to pit two titans—Claude and Gemini—against each other using their free tiers to see which handled this refactor better.

Round 1: Claude – The Overzealous Architect

Claude is a developer favorite for a reason. When I fed it my requirements, it responded with a massive "drop" of code: Shell scripts, Systemd services, timer files, test scripts, and installation scripts.

The Issues:

• The Logic Hallucination: The requirements included a "shutdown hook" to pause the power-off. Claude misinterpreted this, refactoring it into a feature that shifted the start time of the uptime window instead.
• Over-Engineering: It designed an overly complex Systemd timer architecture threating the mid to long-term maintenance.
• The Velocity Trap: On the free tier, Claude’s verbosity and velocity were a bottleneck. It insisted on regenerating every single file for minor changes, hitting rate limits, and requiring several minutes for each iteration.

Round 2: Gemini – The Agile Iterative Partner

I switched to Gemini. The experience was the polar opposite.

The Wins:

• Precision: Gemini didn't bury me in files I didn't ask for. It focused exactly on the snippet I needed.
• Speed: The generation was lightning-fast, which is crucial when you are in the "flow state" of refactoring.
• Frontend Mastery: The biggest hurdle was the CSS/HTML/JS refactoring for the new scheduling UI. Gemini helped me iterate on the look and feel, ensuring the "0 to many" time ranges worked perfectly, including an appealing look and feel for the front end.

Pro-Tip on Prompting:

• Success here required "smart" prompting. I initially started with overly complex, multi-layered prompts that led to hallucinations.
• The breakthrough came when I reverted those changes and pivoted to a step-by-step refactoring strategy: Analyzing the code structure first and then requesting surgical updates was the key to success.

Gemini acted less like a distant architect and more like a pair-programmer, helping me finalize the API, Linux cahnges and front-end in real-time.

The Result: 6 Hours to Peace of Mind

After six hours, the feature was live. Today, the system doesn't just block sites; it enforces the most important thing a growing child needs: rest.

Real-World Output: The Access Violation Alert

If the system is accessed outside of the allowed window, I get an automated alert that looks like this:

⚠️ Access VIOLATION! - 2026-02-17 03:18
System Auto-Shutdown Alert

Current day: 2 (Tuesday) | Time: 03:18 

Configured Ranges: 07:30 - 21:30
✗ Outside all configured time ranges. Next window: 07:30

Hostname: Family-PC-01
The system will shutdown in 60 seconds.

The Control Center: Dashboard and Visibility

The frontend overhaul focused on "glanceability"—the ability to see exactly what restrictions are active without digging through menus.

Key Dashboard Features:

• Real-Time Uptime Metrics: A quick-glance counter showing the total hours the computer is permitted to be powered on for all days of the week.
• Dynamic Range Breakdown: A detailed view of today’s specific time windows (e.g., 07:30–08:30, 16:00–21:00), allowing for easy verification of "freedom windows."
• Firefox Access Sync: A dedicated status indicator for the browser's "Safe Zone." Outside of these specific hours, any restricted websites will only be allowed in the next time range.

Granular Scheduling: Power and Browser Control

The core of the refactor was the scheduling engine. The interface now allows for high-precision management of the computer’s lifecycle and the browser’s "Safe Zone."

1. System Power Configuration

The scheduler supports 0 to N time ranges for every day of the week.

• Precision: Configure access windows with 1-minute accuracy.
• Total Lockdown: Setting zero ranges for a specific day completely prevents the computer from being used, providing a "digital detox" by default.
• Dynamic Flexibility: Easily split time between morning sessions and evening homework hours.

2. Firefox "Safe Zone" Synchronization

Located at the bottom of the configuration screen is the Firefox access logic. This defines exactly when a child can visit "restricted but temporarily allowed" sites.

Comparison: AI Coding Assistants (Free Tiers)