今日已更新 166 条资讯 | 累计 20138 条内容
关于我们

标签:#home

找到 163 篇相关文章

AI 资讯

Debugging LACP Instability in a Transparent OPNsense Bridge

I run a transparent OPNsense bridge between a UniFi Dream Machine Pro and the rest of my LAN. It is deliberately boring at Layer 3: the UDM keeps routing, DHCP, DNS, firewall policy, WAN handling, and VLAN definitions. OPNsense sits inline as a Layer 2 bump in the wire. The interesting part is that both sides of that bump use LACP . I already wrote the build/configuration guide for this setup here: Building a Transparent LAGG (LACP) Bridge with OPNsense, UDM, and UniFi - A Practical Guide . That article explains how the bridge was built, how the LAGG devices were configured, and why I wanted the firewall to remain transparent. This article is the other half of the story: what happens when that kind of setup fails in a non-obvious way. Not a clean outage. Not a single "the network is down" moment. Just enough instability to make everything feel wrong. 1. Topology and Failure Surface The topology looked like this: +----------------------+ | UniFi Dream Machine | | kantharos-udm-pro | +----------+-----------+ | LACP aggregate, 2 x 1G | OPNsense lagg0 "ingresslagg" igc1 + igc2, LACP | +----------v-----------+ | OPNsense bridge0 | | "laggbridge" | +----------+-----------+ | OPNsense lagg1 "egresslagg" igc4 + igc5, LACP | LACP aggregate, 2 x 1G | +----------v-----------+ | UniFi USW-Lite-16 | | downstream LAN | +----------------------+ On OPNsense, the relevant interfaces were: igc1 + igc2 -> lagg0 -> ingresslagg -> toward UDM igc4 + igc5 -> lagg1 -> egresslagg -> toward USW lagg0 + lagg1 -> bridge0 -> laggbridge The bridge is a FreeBSD bridge. The aggregates are FreeBSD lagg(4) interfaces using LACP. OPNsense exposes those through its Interfaces > Devices UI. The expected healthy OPNsense state is: laggproto lacp status: active laggport: igcX flags=<ACTIVE,COLLECTING,DISTRIBUTING> laggport: igcY flags=<ACTIVE,COLLECTING,DISTRIBUTING> Those three member states matter: ACTIVE : the member is participating in the LACP bundle. COLLECTING : the member may receive traffic. DIS

2026-06-06 原文 →
开发者

This chunky little tablet got my kid to clean up his toys

Never underestimate the power that a cheap tablet holds over a kid under six. The Skylight Buddy is a device with one job: to be a cute little guy that helps your kid track routines and chores. It's $139.99, plus an optional subscription. And to my surprise, even though it offers a pretty limited set […]

2026-06-05 原文 →
开发者

Building MemOrLearn: An Adaptive Learning Platform That Makes Memorisation Actually Enjoyable

How I combined spaced repetition, adaptive algorithms, and clean UX to create a multi-purpose learning tool. I’ve always believed that memorisation doesn’t have to feel like a chore. After years of using (and sometimes getting frustrated with) existing tools, I decided to build my own. That’s how MemOrLearn was born in early 2026. MemOrLearn is a web-based adaptive learning platform that brings together flashcards, typing practice, math drills, and Bible memory tools — all powered by intelligent spaced repetition and performance-based adaptation. The Core Idea: Most flashcard apps follow a rigid spaced repetition schedule. I wanted something smarter — a system that actually adapts to the user in real time. If a learner is struggling with a concept, the algorithm increases review frequency and offers slight variations. If they’re crushing it, reviews are intelligently spaced out. This dynamic approach is what makes the experience feel responsive and human. Key Features: Adaptive Flashcards: The heart of the platform. Users can create decks or browse public ones. The system tracks performance per card and automatically adjusts difficulty and frequency. Clean, fast, and minimal interface — exactly how I like my tools as a developer. Typing Tutor: Built to help users improve speed and accuracy through gamified, adaptive drills. It adjusts to your current level so you’re always progressing. Math Drills: Focused practice on math facts with real-time adaptation. The system identifies weak areas quickly and targets them without wasting time on mastered content. Bible Memory Mode: A specialized tool many users love. It applies the same adaptive principles to Scripture memorization, making it effective for individuals, families, and small groups. Teacher / Parent Dashboard: A clean admin view that lets educators assign work, monitor progress, and adjust settings per student. Built with simplicity in mind. Technical Approach (For Fellow Builders): I focused on keeping the back

2026-06-05 原文 →
AI 资讯

Dreame’s L20 Ultra robovac is an unbeatable deal for $280

The Dreame L20 Ultra isn’t the company’s newest model, but it’s still a great robovac / mop hybrid that offers strong performance while requiring very little day-to-day maintenance thanks to its included trash bin and AI obstacle avoidance. Verge readers can get for its best-ever price right now. Originally $1,400 when it launched in 2023, […]

2026-06-03 原文 →
AI 资讯

SwitchBot’s acquisition of Nanoleaf is about more than lighting

Smart lighting company Nanoleaf has been acquired by OneRobotics, the parent company of SwitchBot. In an exclusive interview with The Verge, Nanoleaf CEO Gimmy Chu says the company will remain independent and that he and his cofounder and COO, Christian Yan, will continue to run it. "Nothing is changing operationally," says Chu, adding that there […]

2026-06-03 原文 →
AI 资讯

Fitting WhisperX large-v3 + a 24B LLM on one 3090: a reproducible context-capping recipe

This is the technical, reproducible version of a fix I shipped on my own homelab. If you want the narrative version, that's on Medium. This one is the recipe: the measurements, the math, the Modelfile, and the exact prompt I gave Claude Code to generate it. Copy-paste friendly. Repo for the dashboard used throughout: https://github.com/SikamikanikoBG/homelab-monitor TL;DR One 24GB RTX 3090, two GPU services: WhisperX large-v3 (STT, 7.7GB peak) and a Devstral Small 24B email-triage LLM (Q4_K_M, ~18.3GB). 18.3 + 7.7 = 26GB → CUDA OOM whenever they overlapped. The LLM was loaded with a 40k context window but the triage job never needed more than ~5–8k tokens. Capped num_ctx to 8192 → KV cache drops from ~6.1GB to ~1.25GB → model footprint ~18.3GB → ~14.2GB . 14.2 + 7.7 = 21.9GB → both resident, zero OOM, no quality loss. The setup Host : openSUSE, Xeon (56 threads), 125GB RAM, 1x RTX 3090 (24GB) GPU svc : WhisperX large-v3 (speech-to-text) GPU svc : Ollama -> devstral-small-2 (24B, Q4_K_M) for background email triage Both services run all the time. The OOM only happened when I dictated to my assistant (WhisperX) while the triage loop was active. Step 1 — Make the contention measurable nvidia-smi shows instantaneous VRAM. It can't show you which service spiked or when two of them overlapped — and an intermittent OOM is a timing problem. You need per-service VRAM history. I use my own dashboard (homelab-monitor) for this. The relevant view is "AI Models", which attributes VRAM per model server and per loaded model, over a time range, with OOM markers and a capacity ceiling line. What the history showed at the overlap window: Service Peak VRAM Devstral 24B (triage) ~18.3 GB WhisperX large-v3 7.7 GB Total ~26 GB on a 24 GB card If you want to reproduce the measurement, the dashboard runs as a single container: git clone https://github.com/SikamikanikoBG/homelab-monitor cd homelab-monitor docker compose up -d --build # open http://<host>:9800 -> AI Models / GPU views (NVIDI

2026-06-03 原文 →
AI 资讯

Stop picking a homelab mini-PC by TDP. The number that decides the power bill is idle watts.

A homelab box that never sleeps runs 8,760 hours a year. So the spec that decides what it costs you is not the one on the box. It is the one nobody prints: how many watts it pulls sitting at the login prompt doing nothing. I kept hitting this while shopping for a Proxmox node, so I put the measured numbers in one place. More on that at the end. First, why the spec sheet lies to you. TDP is a thermal budget, not a power reading TDP is the heat the cooler has to handle at full tilt. It is a design target for the heatsink, not a measurement of what the chip draws, and it says almost nothing about idle. Your homelab box spends 95%+ of its life idle, so the number that runs up the meter is idle wall power, and that number is never on the product page. The arithmetic is unforgiving. One watt running continuously is 8.76 kWh a year. So the gap between a 7 W box and a 35 W box is not 28 watts, it is about 245 kWh a year, every year, for as long as the box is on. Plug in your own rate to get the dollars; the point is the gap compounds. Where TDP actively misleads you A few measured results from the dataset I'll link below, all from third-party wall-meter readings, not vendor claims: The new N100 wave is genuinely low. A Minisforum UN100C measures 5 to 7 W at idle. Beelink, GMKtec and Trigkey N100 boxes land in the 6 to 10 W range. For a Pi-hole, a few containers and some light VMs, this tier is hard to beat on running cost. AMD mini PCs idle far higher than their marketing suggests. A Minisforum UM790 Pro measures 25 to 45 W at idle. A Beelink SER6 Pro lands at 20 to 35 W. These are fast little machines, but if you picked one expecting "small box, small draw," the meter disagrees, and over a year that delta is real money. Newer and higher-TDP is not lower-idle. A Dell OptiPlex 7060 Micro idles just over 18 W on its 65 W-TDP desktop chip. The older 7070 with a six-core part sits around 13 W, and the low-power "T" SKUs lower still. The CPU's TDP class predicted idle better tha

2026-06-02 原文 →
AI 资讯

Your NAS Is Loud Because of Docker and Syncthing (and How to Fix It)

You buy a NAS for silent, always-on storage. It sits in a corner, humming quietly, doing its thing. Then you install Docker. Then Syncthing. Then a few containers. Suddenly the HDDs never stop. Seeking, spinning, clicking. Not occasionally - constantly. At 2am you can hear it from the next room. This is what happened, why it happens, and how to make it stop. What's Actually Causing the Noise Mechanical HDDs make noise when the read/write head moves. The more random the I/O - small reads and writes scattered across the disk - the more seeking, the more noise. Sequential writes to a single file are quiet. Random I/O across thousands of small files is loud. Docker and Syncthing are both pathological for HDDs in different ways. Docker overlay2 Docker's default storage driver is overlay2. Every container runs on top of layered filesystems - the image layers are stacked, and a thin writable layer sits on top for each running container. Every file operation inside a container that touches a file from a lower layer triggers a copy-on-write : the entire file gets copied up to the writable layer before the write happens. On an SSD this is fast and silent. On spinning HDDs with mechanical heads, every copy-on-write is a seek, a read, and a write - often scattered across the disk. And it's not just copy-on-write. Docker's overlay2 metadata lives in small files across a deep directory tree. Container startup reads dozens of these. Log rotation writes to them. Health checks touch them. Any container doing anything at all generates constant scattered I/O. Syncthing's 60-Second Heartbeat Syncthing uses BoltDB as its internal database - it stores file indexes, sync state, and peer information there. BoltDB flushes to disk every 60 seconds regardless of whether anything changed. On a busy sync folder with thousands of files, this flush isn't a single sequential write. It rewrites pages across the B-tree structure, which means multiple seeks across the database file. Quiet when it's a

2026-06-02 原文 →
AI 资讯

Building a home server with a mini PC

Having a server at home opens up a huge range of possibilities. I'd been thinking about setting one up for a while, and when I finally got started, I realised that half the process was simply deciding what to buy and what to install. So what is a home server actually good for? There are obvious advantages like cutting SaaS costs or gaining privacy, but there's one that matters more to me than all the others: learning . In this post I'll walk through the process, the options I considered and why I ended up building my server around a Beelink S12 Pro running Proxmox VE . Why a mini PC? The first decision is form factor. The most common options are: An old PC or laptop from the cupboard. It works, but it's usually noisy, consumes a lot of power and takes up too much space. A Raspberry Pi. Small and incredibly power-efficient, but limited in RAM and processing power for running several services at once. A NAS. A solid choice if storage is the main priority, but the price climbs quickly. A mini PC. Small, silent, low power consumption, reasonable price. Clear winner. The mini PCs I considered In 2025, there are three families that make sense for a home lab: Intel N95 / N100 is probably the most popular choice right now for this kind of use. Very good energy efficiency, full virtualisation support and highly competitive prices. The N100 is more efficient than the N95; the N95 wins slightly on raw performance but at the cost of a bit more power draw. There are countless manufacturers building models around these chips, and the difference between them is usually minimal: what varies is the connectivity, the stock RAM and the after-sales support. Mac Mini deserves a mention because it's one of the most well-known options on the market. Performance is excellent and power consumption is surprisingly low, but for me the problem is the price — clearly higher than a Chinese mini PC — and I don't need something like that to get started. Fanless mini PCs (no fan). Fully passive mod

2026-05-31 原文 →